Oauth2.0とは
OAuth 2.0 は、認可のための業界標準プロトコルです。OAuth 2.0 は、Web アプリケーション、デスクトップ アプリケーション、携帯電話、およびリビング ルーム デバイスに特定の承認フローを提供しながら、クライアント開発者の簡素化に重点を置いています。
https://oauth.net/2/
わかりやすいOauthの解説はこちら
Open ID Connectとは
クライアントは、承認サーバーによって実行される認証に基づいてエンドユーザーの身元を確認し、エンドユーザーに関する基本的なプロファイル情報を相互運用可能な REST のような方法で取得できます。
OpenID Connect を使用すると、Web ベース、モバイル、および JavaScript クライアントを含むすべてのタイプのクライアントが、認証されたセッションとエンド ユーザーに関する情報を要求および受信できます。仕様スイートは拡張可能で、参加者は必要に応じて ID データの暗号化、OpenID プロバイダーの検出、ログアウトなどのオプション機能を使用できます。
https://openid.net/connect/
わかりやすいOpen ID Connectの解説はこちら
Cognitoのエンドポイント設定
Cognitoの認証に、Open ID Connectを使用できます。
IDプロバイダーの設定を、コンソール画面から行うことが可能ですが、今日は、各エンドポイントがどのような処理を行なっているかを見ていきたいと思います。
認証エンドポイント
Cognitoからのリクエストを受け、IDプロバイダーの認証認可ページにリダイレクトします。
- リクエスト
- cliend_id
- IDプロバイダー側で作成したアプリのクライアントID
- redirect_uri
- IDプロバイダーとの対話が終わった後に遷移するリダイレクト先
- scope
- 付与されたアクセストークンでアクセスできるリソースのスコープ
- open_idの設定が必要
- response_type
- レスポンスタイプを設定。コードのいずれかでないといけない。
- レスポンスタイプによる処理の違いはこちら
- https://qiita.com/TakahikoKawasaki/items/4ee9b55db9f7ef352b47
- state
- 認可サーバがstateの値をリダイレクト時に含めることで、CSRF対策を行う
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
- レスポンス
- code
- 認証コード。最大10分のみ有効。
- state
- クライアントから受信したstateがそのまま入る
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
トークンエンドポイント
認証コードを元に、アクセストークンを取得する
- リクエスト
- grant_type
- “authorization_code”の設定が必要
- code
- 認可サーバから受信したコードの設定が必要
- redirect_uri
- 認証エンドポイントリクエストに設定したredirect_uriと同一の値
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
- レスポンス
- access_token
- 発行されたアクセストークン
- token_type
- トークンタイプ(”bearer”や”mac”など)
- expires_in
- アクセストークンの寿命
- scope
- クライアントからリクエストされたスコープ
- state
- 認証エンドポイントリクエストで設定したstateがそのまま入る
- refresh_token
- リフレッシュトークン
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
ユーザー情報エンドポイント
ユーザー情報を取得し、cognitoの会員情報として登録する
- リクエスト
- Authorization
- アクセストークン
GET /userInfo HTTP/1.1
Authorization: Bearer <access_token>
Host: server.example.com
- レスポンス
- sub
- id
- email
- メールアドレス
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"sub": "248289761001",
"email": "janedoe@example.com"
}
まとめ
上記のエンドポイントとの通信を経て、Open ID Connectは、Cognitoと通信を行っているそうです。
自前でIDプロバイダーとのやりとりを実装するのは骨が折れそうですね、、
Cognitoにエンドポイントパラメータを設定するだけで、よしなに認可サーバとして機能してくれます。