こんにちは、富士榮です。
最近Updateできていなかった自作OpenID Providerについて、そろそろログイン機構の実装戦略について考えてみたいと思います。
その前にこれまでのおさらいです。
その前にこれまでのおさらいです。
- まずは全体像から
- まずOpenID Providerの情報をRelying Partyに提供する
- OpenID Providerを作る)認可エンドポイントを作る
- OpenID Providerを作る)トークンエンドポイントを作る
- OpenID Providerを作る)UserInfoエンドポイントを作る
- OpenID Providerを作る)response_typeを実装する
- OpenID Providerを作る)Hybridフローを実装する
- OpenID Providerを作る)Pairwise識別子を実装する
- OpenID Providerを作る)scopeの定義と返却する属性
- OpenID Providerを作る)定義済み属性の値として何を返却すべきか
- OpenID Providerを作る)トークンエンドポイントにクライアント認証を実装する
- OpenID Providerを作る)認可エンドポイントでクライアントの登録状態を検証する
- OpenID Providerを作る)ユーザ情報をデータベースから取得する
- OpenID Providerを作る)login_hintを使ってログインユーザを指定する
- OpenID Providerを作る)仮名に加えて匿名をサポートする
- OpenID Providerを作る)ユーザ認証方式について考える
今回、最低限実装したい機構としては、
- CSRF対策を行う
- Passkeyで認証する
- セッション管理(認証セッションがなければ認証を求める)を行う
- 認証が終わったら元のURLへ戻す
くらいかな、と思います。
となると、骨組みとしてはこんな感じかと。(node.js + Express前提です)
- 認証ミドルウェアの実装
- 認証セッション確認
- 認証セッションがあればnext()で呼び出し元へ
- 認証セッションがなければ、
- セッションに呼び出し元のURLを保存
- セッションと紐づけた状態でCSRFチェックのトークン発行
- ログイン画面へリダイレクト(CSRFトークンを埋め込む)※今回、認証方式はPasskeyのみを考えており、Passkeyの場合はChallengeの生成も行うので兼用しても良いのかも。この辺はritou先生がコメントしてくれるでしょう
- ログイン画面の実装
- 認証ミドルウェアから呼び出される
- ログイン画面のレンダリング
- PasskeyのブラウザAPIの実装
- ブラウザAPI実行結果をPOSTする
- ログイン結果検証APIの実装
- ブラウザAPIの実行結果の検証(CSRF対策としてのChallengeの検証も含む)
- 検証に成功したら認証セッション生成
- セッションに保存してある呼び出し元のURLへ処理を戻す
ぼちぼち実装始めてますので、まとまったら投稿していきたいと思います。
では。
0 件のコメント:
コメントを投稿