Zenn
2️⃣

ID周りをやりたいエンジニアにすすめたい学習ステップ(2) : 複数アプリケーションが絡むID管理

2024/04/08に公開
Security
教育
identity
tech

ritouです。

こちらの記事の続きです。

https://zenn.dev/ritou/articles/522369cd4a7747

前回の記事の振り返り

3行でまとめると

  • まずは単一アプリケーションのID管理について解像度を上げてみよう
  • Webアプリケーションフレームワークを使って新規登録から退会までざっくり動作確認してから、色々いじったり調べてみるのが良いよ
  • セキュリティ関連の機能とか、新規登録時の身元確認、ログイン方法を拡張してみよう

といったところです。個人的にはこれは全エンジニア向けの研修であってもいいぐらいのものだと思います。

今回の内容

タイトルにある通り、複数のアプリケーションが関わる部分に入っていきましょう。

というか、OAuthとOIDCやりたいんですよね？え?SAML?

まずはID連携のベーシックな部分に触れていきましょう。
プロトコルは混ざっちゃっていますが、順番としてはこんなのはどうでしょう。

  1. OAuth 2.0のClientとしての機能を設計/実装する
  2. OIDCのRPとしての機能を設計/実装する
  3. OAuth 2.0のAuthorization Server/Resource Serverとしての機能を設計/実装する
  4. OIDCのIdPとしての機能を設計/実装する

自分で考え、手を動かし、誰かにレビューしてもらうのがベストかとは思いますが、手早く動作まで持っていける既存のMiddlewareやライブラリの実装を読みつつ導入し、実際にどのような処理が行われるかを調べるだけでも理解が深まるでしょう。

それぞれについて目的などを整理しましょう。

1. OAuth 2.0のClientとしての機能を設計/実装する

いいですか？OAuth認証じゃないですよ！！！

ここでは

  • 安全な認可フロー
  • Access Token/Refresh Tokenの管理
  • 同期/非同期のリソースアクセス

についての理解を深めましょう。

特に最後のところ、

  • 同期 : ブログ記事を書いているときに外部サービスから画像を引くような、ユーザー操作に同期したリソースアクセス
  • 非同期 : 指定した投稿日時にSNSに投稿するみたいな、ユーザー操作とは非同期のリソースアクセス

という2種類ではエラーハンドリングなど違いがあると思うので、その辺りに触れて考えてもらいたいですね。

当然ながら、ここでは OAuth 2.0の各種トークンのAccess Token/Refresh Tokenのライフサイクルを意識することが重要です。

2. OIDCのRPとしての機能を設計/実装する

次はOIDCのRPです。気軽に行うには前回作ったアプリケーションにソーシャルログイン機能を加える、でも良いでしょう。

  • 安全なOIDC認証フロー
  • 外部サービスのユーザー情報との紐付け管理
  • 非同期のユーザー情報取得

OIDCの認証フローの部分では、IdPのログイン状態によって挙動が変わります。
良い機会なので IdPのログインセッションのライフサイクルに注目し、取りうる状態とその際の挙動についてRP目線で整理しておくことも重要でしょう。

いわゆるソーシャルログインにおいて、自サービスのユーザーとIdPのユーザーの紐付けを避けては通れません。
IdPのアカウントのライフサイクルを意識することが重要です。 紐付けデータを持たずにメールアドレスをキーにして参照/連携する場合は意図せぬ挙動を生み出しかねないので注意が必要です。

OIDCのUserInfo Endpointへのリクエストは非同期でユーザー情報を取得する仕組みです。
ソーシャルログインのタイミング以外でもユーザー情報を参照する必要がある場合を考え、さらに自サービスに影響がありそうな変更があったらどのように対応するかを考えてみましょう。

3. OAuth 2.0のAuthorization Server/Resource Serverとしての機能を設計/実装する

1で接続する認可サーバー、APIサーバーの方を作れるようになりましょう。
最初からこれをやろうとするとものすごいハードルが高い気がするでしょう。実際作業量は多いと思うのでまずは既存のライブラリなどを入れつつ実装を読むのを先にやるべきでしょう。
ただ、これまでの段階を踏んでいれば実装しなければならないことがイメージしやすくなっているはずです。

  • 認可フローからのトークン発行方法
  • Client, アクセス許可、各種トークンの管理
  • APIのトークン検証

こちらも拡張仕様は一旦無視でおkです。
(ちなみに、この辺りを考えていくとAuthlete社の目の付け所すげぇってなると思います。)

4. OIDCのOPとしての機能を設計/実装する

3で触ったものをOIDCにも対応してみましょう。こちらも拡張仕様は一旦無視でおkです。

  • 認可フロー -> 認証フローへと改修
  • IDTokenを返す
  • UserInfo Endpointを実装

3からの差分としてはこんな感じですが、実際は色々こまかいもの色々作らなきゃーってなります。
今回はこの辺りにしましょう

今回のまとめ

今回の内容は、OAuth/OIDCのベーシックな部分に手を出したらどうかという話でした。
最初にClient/RPの実装を見た後に、AuthZ Server,RS/IdPの実装を見ていくことで差分を抑えつつ進んでいけると思います。

拡張仕様には一切触れないこと、こまけぇセキュリティプラクティスは一旦無視でおkです。まず動かしましょう。

次のステップ

自分も含めて、最近は会社内に認証基盤なるものが作られることが増えてきました。

  • 認証基盤を使うサービス側が気をつけること
    • 今回の1,2の深掘り
  • 認証基盤側が気をつけること
    • IdPかつRPみたいなこともあり得る
    • 星の数ほどある拡張仕様

みたいに分岐しつつ、それぞれでどこを細かく見ていくかみたいなところをまとめられたら良いかなと思っています。

だいぶ沼に潜ったつもりですか？すみません、ここが入り口です。

ではまた。

Discussion