OIDC＠SSO¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. OIDC：OpenID Connect (外部ID連携)¶
OIDCとは¶
SSOの一種である。
OAuthをベースとして、認証フェーズを追加し、認証/認可を実装する。
そのため、OAuthの一種ともいえる。
02. OIDCの仕組み¶
アーキテクチャ¶
認証フェーズの委譲先のIDプロバイダー、ログインしたいWebサイト、から構成される。
クレーム¶
クレームは認証情報の要素である。
委譲元のクライアントは、IDプロバイダーから取得したクレームを認証情報として扱い、認可処理を実行する。
| クレーム | 説明 |
|---|---|
sub |
アカウントの識別子 |
profile |
アカウントのプロフィールURL |
name |
アカウントの氏名 |
email |
アカウントのメールアドレス |
phone |
アカウントの電話番号 |
address |
アカウントの住所 |
| ... | ... |
認可リクエスト時のクレームの取得¶
▼ scopeパラメーター¶
認可リクエスト時に、scopeパラメーターでクレームグループを指定し、クレームを取得できる。
IDプロバイダーは、指定したクレームグループに対応したクレームをIDトークンに設定し、クライアントに返信する。
委譲元のクライアントは、取得したクレームを認証情報として扱い、認可処理を実行する。
| クレームグループ | 取得できるクレーム (認証情報の要素) |
|---|---|
openid |
これは、OIDCの場合に必須である。トークンエンドポイントから、アクセストークンに加えてIDトークンを発行できるようになる。 |
profile |
name、family_name、given_name、middle_name、nickname、preferred_username、profile、picture、website、gender、birthdate、zoneinfo、locale、updated_at |
email |
email、email_verified |
phone |
address |
address |
phone_number、phone_number_verified |
| ユーザー定義のクレームグループ | 自由にクレームを設定できる |
▼ claimsパラメーター¶
認可リクエスト時に、claimsパラメーターで特定のクレームを指定し、クレームを取得できる。
クレームの指定の仕方が複雑らしい...
03. トークンの検証¶
IDトークン検証¶
アクセストークンの発行前に、IDトークンの有効期限や発行元認証局が正しいかどうかを検証する。
アクセストークン検証¶
発行後のアクセストークンが有効期限や発行元認証局が正しいかどうかを定期的に検証する。
以下のいずれかの方法で検証できる。
- 認可サーバーのイントロスペクションエンドポイントにリクエストする
- 認可サーバーから取得した公開鍵を使用して、アクセストークンの署名を検証する
04. OIDCの種類¶
ベースになっているOAuthと同様にして、OIDCには仕組み別に『認可コードフロー』『暗黙的フロー』『リソースオーナー・パスワード・クレデンシャルズフロー (ダイレクト・アクセス・グラント) 』などがある。
05. OAuthとの違い¶
トークンの違い¶
OIDCはOAuthの拡張であるため、仕組みは非常に似ている。
OIDCでは、OAuthとは異なり、アクセストークン (JWT仕様かどうかはツール次第) だけでなくIDトークン (必ずJWT仕様) の使用する。
また、OAuthの脆弱性に対処できる。
- https://auth0.com/jp/intro-to-iam/what-is-oauth-2
- https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe
- https://dev.classmethod.jp/articles/auth0-access-token-id-token-difference/#toc-3
- https://zenn.dev/uma002/articles/152fcef798730b#%E3%81%AA%E3%81%9C%E8%84%86%E5%BC%B1%E6%80%A7%E3%81%8C%E7%94%9F%E3%81%BE%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%8B
06. 認可コードフロー¶
仕組み¶
OAuthの認可コードフローと仕組みが似ており、アクセストークンだけでなくIDトークンも使用する。
短命な認可コードを送信すると、IDプロバイダーからリフレッシュトークンを含むアクセストークンとIDトークンを取得できる。
運搬¶
アクセストークンをAuthorizationヘッダーで運べる。
07. SLO：シングルログアウト¶
シングルログアウトとは¶
SSOをログアウトする仕組みのこと。
複数の方式を組み合わせてSSOをログアウトする。
RP-Initiated¶
▼ シングル¶
▼ グローバル¶
記入中...
フロントチャネル¶
▼ シングル¶
▼ グローバル¶
フロントエンドのブラウザが、IDプロバイダーのログアウトエンドポイント (<IDプロバイダーのドメイン>/<IDプロバイダーによる>) にPOSTリクエストを送信し、全てのアプリケーションからログアウトする。
バックチャネル¶
▼ シングル¶
▼ グローバル¶
IDプロバイダーが、バックエンドのいずれかのアプリケーションのログアウトエンドポイント (<アプリケーションのドメイン>/<IDプロバイダーのクライアントパッケージによる>) にPOSTリクエストを送信し、そのアプリケーションでログアウト処理を実行する。
セッションの有効期限が失効し、バックエンドのアプリケーションが起点となってログアウト処理を始める場合、それはバックチャネルである。
また、フロントエンドのブラウザがバックエンドのアプリケーションにログアウトリクエストを送信し、これが起点となる場合もバックチャネルである。