なぜソーシャルログインの際にemailをキーにして参照するのか
ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 の 初日の記事です。 こちら、参加者を募集中です！気軽に参加してみてください！してくれよ！はよ！ なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ
サービスの新規登録とログインを分けるかまとめるかの考え方
ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2021 の18日目の記事です。(代わりに書いた) 今回のお話は 新しいサービス作る時とか、登録/ログインフロー考えるよね？考えない？おじさんそう言うお仕事してるの パスワードレスな認証方式やID連携とか使いだすと、登録もログインも一緒でええかみたいな話も出てくるでしょ？こない？おじさんとこは出るの 分けたまま、一緒にする場合にそれぞれ気をつけないといけないことを整理しましょ というお話です。 1. パスワード認証時代は分けてりゃ良かった パスワード認証の場合、新規登録とログインでUXの要件が異なります。 新規登録 : ユーザーが主張する識別子や連絡先としてメールアドレスやSMS番号を確認し、パスワードを登録させる ログイン : ユーザーが主張する識別子とパスワードを入力させて検
OIDCを用いたID連携における "確認済みメールアドレス" の使い方と注意点
ritou です。 前の記事でちょっと確認済みメアドについての記載をしたあと、Twitterでちょっとやりとりしたり個別にDMで質問が来たりしたのでまとめます。 まとめ "確認済みメアド" のユースケースはいくつかある 新規登録時に自サービスで確認処理を行わずに利用 未登録ユーザーがソーシャルログインしてきた時に既存ユーザーとの紐付け IdPからもらった確認済みメアドをそのまま使っていい場合とそうじゃない場合がある 自サービスで提供しているメールアドレスかどうかで変わる部分を許容するかどうか email_provided のようなclaim があると便利かもしれない 確認済みメアドのユースケース 新規登録時の確認処理をスキップ これはID連携、ソーシャルログインのメリットとしてずっと言われているものです。 IdPで確認済みなのでRPは確認せずに信用して使おう というお話です。 よく知られて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
