SSO＠認証アーティファクトによる分類¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. SSO：Single Sign On¶
SSO とは¶
Web サイトごとに認証フェーズと認可フェーズを行うのではなく、認証フェーズは他の Web サイトに統一的に委譲し、認可フェーズだけは Web サイトごとに実施する。
セキュリティ強度の向上というよりは、利便性の向上のために使用することが多い。
そのため別途、SSO と二要素認証などを組み合わせて、セキュリティ強度を向上させたほうがよい。
二要素認証と SSO を組み合わせる場合、認証フェーズの委譲先で二要素認証を追加することになる (例：GitHub アカウントを用いた SSO 時に、ワンタイムパスワードの入力も要求される) 。
SSO の仕組み¶
(1)-
API クライアント (あるいは認証プロキシ) が、HTTP リクエストに ID とパスワードを設定し、IP プロバイダーにリクエストを送信する。
(2)-
ID プロバイダーが、クライアントを『認証』し、クライアント側にアクセストークンを発行する。
(3)-
クライアントが、HTTP リクエストのヘッダーにアクセストークンを設定してリクエストする。
(4)-
トークンが『認可』されれば、API 側がデータをレスポンスする。
SSO には、認証フェーズと認可フェーズがあり、3 個の役割が定義されている。
| 役割 | 説明 | 例 |
|---|---|---|
| API クライアント | API へリクエストを送信したいサーバーのこと。 | Ouath 認証の仕組みにおけるクライアント。 |
| ID プロバイダー | トークン (例：アクセストークン、ID トークンなど) を作成するサーバーのこと。 | Ouath 認証の仕組みにおける認可サーバー。 |
| API サーバー | クライアントに対して、リソースのレスポンスを返信するサーバーのこと。 | Ouath 認証の仕組みにおけるリソースサーバー。 |
API クライアント¶
▼ ID プロバイダーとの通信¶
API クライアントは、ID プロバイダーに資格情報 (例：クライアント ID、クライアントシークレットなど) を送信する必要がある。
これらの資格情報は ID プロバイダーで事前に発行しておく。
ただし、API クライアントから ID プロバイダーにこれらを直接する代わりに、認証プロキシ (例：OAuth2 Proxy、Dex など) に送信してもよい。
その場合、API クライアントが認証プロキシにリクエストを送信した後、認証プロキシは ID プロバイダーからアクセストークンを取得し、API クライアントを認証する。
▼ ステータスコードの選定¶
認証フェーズにて、誤ったトークン (例：アクセストークン、ID トークンなど) が発行されたことを表現したい場合、401 ステータスを使用する。
認可フェーズにて、正しいトークンが発行されたが、トークンの所有者に参照権限がないことを表現したい場合、403 ステータスを使用する。
ID プロバイダー¶
▼ ID プロバイダーの種類¶
- Auth0
- Keycloak
- AWS Cognito (代わりに認証プロキシとしても使用できる)
- Google Cloud Auth
