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 プロバイダーは、取得したクレームグループに対応したクレームを 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 |
phone_number、phone_number_verified |
address |
address |
| ユーザー定義のクレームグループ | 自由にクレームを設定できる |
▼ claims パラメーター¶
認可リクエスト時に、claims パラメーターで特定のクレームを指定し、クレームを取得できる。
クレームの指定の仕方が複雑らしい...
03. トークンの検証¶
ID トークンの検証¶
ID トークンの情報 (署名部分、有効期限、発行元など) から、ID トークンの署名を検証できる。
アクセストークン署名検証¶
▼ JWT 仕様の場合¶
アクセストークンの情報 (署名部分、有効期限、発行元など) から、アクセストークンの署名を検証できる。
以下のいずれかの方法で検証できる。
- 認可サーバーから取得した公開鍵 (一般的)
- 認可サーバーから取得した共通鍵
- 認可サーバーのイントロスペクションエンドポイント
04. OIDC の種類¶
ベースになっている OAuth と同様にして、OIDC には仕組み別に『認可コードフロー』『暗黙的フロー』『リソースオーナー・パスワード・資格情報ズフロー (ダイレクト・アクセス・グラント) 』などがある。
05. OAuth との違い¶
目的¶
OIDC は認証の仕組みである。
一方で、OAuth は認可の仕組みである。
トークンの違い¶
OIDC は OAuth の拡張であるため、仕組みは非常に似ている。
OIDC では、OAuth とは異なり、アクセストークン (JWT 仕様かどうかはツール次第) だけでなく ID トークン (必ず JWT 仕様) の使用する。
また、OAuth の脆弱性に対処できる。
06. 認可コードフロー¶
仕組み¶
OAuth の認可コードフローと仕組みが似ており、アクセストークンだけでなく ID トークンも使用する。
短命な認可コードを送信すると、ID プロバイダーからリフレッシュトークンを含むアクセストークンと ID トークンを取得できる。
Keycloak の場合¶
▼ 認可リクエスト送信¶
アプリから Keycloak 宛に認可リクエストを送信する。
$ curl http://<Keycloakのドメイン>/realms/oidc-sample/protocol/openid-connect/auth?response_type=code&client_id=rp1&redirect_uri=http://<アプリケーションのドメイン>/oidc&scope=openid
▼ 認可レスポンス受信¶
Keycloak は認可レスポンスを受信し、アプリに対してリダイレクトを送信する。
$ curl http://<アプリケーションのドメイン>/oidc?session_state= ... &code=<認証コード>
▼ トークンリクエスト送信¶
認可コードを使用して、Keycloak にトークンリクエストを送信する。
ID トークンとアクセストークンを取得できる。
$ curl -d "grant_type=authorization_code&code=<認証コード>&redirect_uri=http://<アプリケーションのドメイン>/oidc&client_id=rp1&client_secret=<Client secret>" http://<Keycloakのドメイン>/realms/oidc-sample/protocol/openid-connect/token
{
"access_token": <アクセストークン>,
"expires_in": 300,
"refresh_expires_in": 1800,
"refresh_token": <リフレッシュトークン>,
"token_type": "Bearer",
"id_token": <IDトークン>,
"not-before-policy": 0,
"session_state": "8468db1c-feb4-4803-bfeb-213149b560cf",
"scope": "openid email profile"
}
▼ ユーザー情報の取得¶
$ curl -H "Authorization: Bearer <アクセストークン>" http://<Keycloakのドメイン>/realms/oidc-sample/protocol/openid-connect/userinfo
{
"sub": <User ID>,
"email_verified": false,
"preferred_username": "admin",
"given_name": "",
"family_name": ""
}
▼ アクセストークンの再作成¶
リフレッシュトークンを使用して、アクセストークンを再作成する。
$ curl -X POST -d "client_id=rp1&client_secret=<Client Secret>&grant_type=refresh_token&refresh_token=<リフレッシュトークン>&scope=openid profile" http://<Keycloakのドメイン>/realms/oidc-sample/protocol/openid-connect/token
運搬¶
アクセストークンを Authorization ヘッダーで運べる。
07. SLO：シングルログアウト¶
シングルログアウトとは¶
SSO をログアウトする仕組みのこと。
複数の方式を組み合わせて SSO をログアウトする。
RP-Initiated¶
▼ シングル¶
▼ グローバル¶
記入中...
フロントチャネル¶
▼ シングル¶
▼ グローバル¶
フロントエンドのブラウザが、ID プロバイダーのログアウトエンドポイント (<IDプロバイダーのドメイン>/<IDプロバイダーによる>) に POST リクエストを送信し、すべてのアプリケーションからログアウトする。
バックチャネル¶
▼ シングル¶
▼ グローバル¶
ID プロバイダーが、バックエンドのいずれかのアプリケーションのログアウトエンドポイント (<アプリケーションのドメイン>/<IDプロバイダーのクライアントパッケージによる>) に POST リクエストを送信し、そのアプリケーションでログアウト処理を実行する。
セッションデータが失効し、バックエンドのアプリケーションが起点となってログアウト処理を始める場合、それはバックチャネルである。
また、フロントエンドのブラウザがバックエンドのアプリケーションにログアウトリクエストを送信し、これが起点となる場合もバックチャネルである。