OAuth 2 仕様では、「リソース サーバー」と「承認サーバー」は必ずしも同じアプリケーションである必要はないと考えていますが、これが実際にどのように実装されているかを理解するのに苦労しています。
例として、次のアプリが存在するとします。
- リソースサーバー
- 認可サーバー
- ウェブフロントエンド
- サードパーティのクライアント アプリ
シナリオ #1: Web フロントエンドへのログイン
- ユーザーがログインフォームを送信
- Web アプリは資格情報を認証サーバー (grant_type=password) に POST し、access_token を受け取ります
- Web アプリは access_token をセッションに保存します
- 後続のリクエストごとに:
- リソース サーバーからリソースを取得し (Authorization ヘッダーに access_token を使用)、Web フロントエンドでレンダリングします。
- 401 が返された場合は、ユーザーをログアウトします (セッションから access_token を削除します)。
シナリオ 2: サードパーティ アプリの承認
- ユーザーが認証サービスからの承認を要求する
- 許可/拒否フォームが表示されます
- ユーザーは、認証コードが存在するクライアント アプリにリダイレクトされます
- クライアント アプリは認証サービス (grant_type=authorization_code) にコードを POST し、access_token を受け取ります
- クライアントはリソース サーバーからリソースを取得します (Auth ヘッダーを使用)
私が理解に苦しんでいる部分は、シナリオ 2 で許可/拒否フォームを表示する前にユーザーを認証する方法です。ユーザーはメインの Web アプリにログインしている可能性がありますが、認証サービスはそれを認識していないため、何らかの方法でユーザーを再度認証する必要があります。認証サービスはログイン/セッションもサポートする必要がありますか?
次の 2 つの理由から、Web アプリが許可/拒否フォームの表示を担当する方が理にかなっているのではないかと考えています。
- すべての UI を単一のアプリに保持します
- ユーザーが既に Web アプリにログインしている場合、資格情報の再送信をユーザーに強制しません。
シナリオ #2 の代替案の 1 つを次に示します。
- ユーザーが Web アプリから承認を要求する
- 許可/拒否フォームが表示されます
- Web アプリが認証サーバーに POST し、新しい許可を作成すると、認証コードが返されます
- Web アプリは、認証コードが存在するクライアント アプリにリダイレクトします
- クライアント アプリは認証サービスにコードを POST し、access_token を受け取ります
これを処理する最良の方法は何ですか? 一般的なコメント、アドバイスなどは素晴らしいでしょう!
ありがとう