認可＠認証/認可¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
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プロバイダー | トークンを作成するサーバーのこと。 | Ouath認証の仕組みにおける認可サーバー。 |
| APIサーバー | クライアントに対して、リソースのレスポンスを返信するサーバーのこと。 | Ouath認証の仕組みにおけるリソースサーバー。 |
APIクライアント¶
▼ IDプロバイダーとの通信¶
APIクライアントは、IDプロバイダーに認証情報 (例：クライアントID、クライアントシークレット、など) を送信する必要がある。
ただし、APIクライアントからIDプロバイダーにこれらを直接するする代わりに、OAuth2.0プロキシ (例：oauth2-proxy、など) やSSOプロキシ(例：dex、など) に送信しても良い。
その場合、APIクライアントが認証プロキシにリクエストを送信した後、認証プロキシはIDプロバイダーからアクセストークンを取得し、APIクライアントを認証する。
▼ ステータスコードの選定¶
認証フェーズにて、誤ったトークンが発行されたことを表現したい場合、401ステータスを使用する。
認可フェーズにて、正しいトークンが発行されたが、トークンの所有者に参照権限がないことを表現したい場合、403ステータスを使用する。
IDプロバイダー¶
▼ IDプロバイダーの種類¶
- Auth0
- Keycloak
- AWS Cognito
- Google Cloud Auth
