メインコンテンツへスキップ
このセクションでは、実装するソリューションの概要として、アイデンティティ管理の詳細、使用するプロトコル、および必要な認証フローについて説明します。

​
アイデンティティ管理

ExampleCo は、IDaaS (Identity as a Service) プロバイダーとして Auth0 を採用することにしました。その理由は、アイデンティティおよびアクセス管理のトレーニング、実装、保守にリソースを割きたくなかったためです。さらに同社は、将来的にこのソリューションを拡張し、モバイルネイティブアプリや、承認済みのタイムシートを社内システムにプッシュするための API を追加することも計画しています。Auth0 なら、このようなアーキテクチャ変更にも最小限の労力で柔軟に対応できます。
IDaaS (Identity as a Service) は、アイデンティティおよびアクセス管理のためのクラウドベースのサービスです。一般的に、シングルサインオン (SSO) 、フェデレーション ID、パスワード管理などの機能が提供されます。

​
使用するプロトコル

次に決めるのは、使用するプロトコルです。 と Connect (OIDC)、または のどれを使うかです。
Auth0 は、コンシューマー向けの Web 製品向けプロトコル (OAuth 2.0、OAuth 1.0、OpenID) とエンタープライズ向けデプロイ用プロトコル (SAML、WS-Federation、LDAP) の両方について、実績があり、広く普及している一般的な ID プロトコルを実装しています。ビジネス要件に最も適したものを自由に選択できます。
OpenID Connect は、OAuth 2.0 仕様ファミリーに基づく認証プロトコルです。OAuth 2.0 プロトコルを通じて配信される、シンプルな JSON () を使用します。

​
OAuth と OpenID Connect (OIDC) の違い

OAuth 2.0 と OpenID Connect (OIDC) は同じものと誤解されがちですが、厳密には異なります。 OAuth 2.0 は、ある Web サイト (コンシューマーまたはアプリケーション) が、別の Web サイト (リソースサーバーまたはプロバイダー) にあるあなたのデータへアクセスできるように認可するためのプロトコルです。たとえば、ある Web サイトに Dropbox アカウント内のファイルへのアクセスを認可したいとします。その Web サイトはあなたを Dropbox にリダイレクトし、ファイルへのアクセスを許可するかどうかを確認します。同意すると、その Web サイトは Dropbox 上のファイルにアクセスする認可を得ます。つまり、OAuth 2.0 の本質はリソースへのアクセスと共有にあります。 一方、OpenID Connect は、OAuth 2.0 プロトコルの上に構築されたシンプルな ID レイヤーです。これにより、複数のサイトで共通のログインを利用できます。OIDC を使って Web サイトにログインするたびに、OpenID サイトにリダイレクトされ、そこでログインした後、元の Web サイトに戻ります。つまり、OIDC の中心にあるのはユーザー認証です。
SAML は XML ベースのプロトコルで、信頼された当事者間で認証と認可の両方を提供します。 SAML と比較すると、OpenID Connect はより軽量でシンプルであり、扱いやすいプロトコルです。SAML は実績があり、強力で柔軟ですが、このアプリの要件では、その柔軟性や高度な機能は必要ありません。ID フェデレーション (SAML を採用する大きな理由の 1 つ) も、ここでは必要ありません。将来的にそれが要件になったとしても、Auth0 で簡単に対応できます。これは、Auth0 が AD (LDAP を使用) を扱う方法と同じです。 こうした理由から、ExampleCo は実装に OpenID Connect を使用します。

​
認証フロー

OpenID Connect は、認証のために複数のフローをサポートしています。ここでは通常の Web アプリを扱うため、Authorization Code Flow を使用します。 フローは次のとおりです。
  1. Web アプリ (OIDC の用語ではクライアント) は、ユーザーエージェント (ブラウザー) を Auth0 (OIDC の用語では認可サーバー) にリダイレクトして、認証リクエストを開始します。
  2. Auth0 は、ユーザーエージェントを介してユーザーを認証します。ユーザーがこのフローを初めて通過するときは、アプリケーションに付与される権限 (たとえば、メッセージの投稿や連絡先の一覧表示) を一覧表示する同意ページが表示されます。ユーザーはサービスにログインし (まだログインしていない場合) 、アプリケーションへのアクセスを認可します。
  3. ユーザーがアクセスを許可すると、Auth0 はユーザーエージェントをアプリケーションにリダイレクトし、その際にクエリー文字列に認可コードを含めます。
  4. アプリケーションは、アプリケーションの認証情報 (client_id と client_secret) とともに認可コードを Auth0 に送信し、トークンを要求します。
  5. Auth0 は、client_id と client_secret を使用してアプリケーションを認証し、認可コードを検証します。有効であれば、Auth0 は IDトークン を返します。
undefined

​
Form Post Response Mode

別の方法として、response_type=id_token&response_mode=form_post を指定した OAuth 2.0 Form Post Response Mode を使用できます。response_type=id_token リクエストパラメーターにより、レスポンスには認可コードではなく IDトークン が直接含まれます。一方、response_mode=form_post では、IDトークン とそのほかの認可レスポンスパラメーターが HTML フォームの値としてエンコードされ、ユーザーエージェントで自動送信されます。この方法を使うと、認可コードを IDトークン に交換する必要がないため、認証フローを最適化できます。ただし、アプリの実装に使用している技術でこれがサポートされている必要があります (ASP .NET Core middleware はこれをサポートしています) 。詳しくは、OAuth 2.0 Form Post Response Mode specification を参照してください。
IDトークン (通常、コードサンプルでは id_token と表記されます) は、ID データを含む JSON Web Token (JWT) です。これはアプリケーションで使用され、ユーザーの名前やメールアドレスなどのユーザー情報を取得するために使われ、通常は UI の表示に使用されます。

​
トークンの詳細

トークンは、トークンベース認証で使用される英数字の文字列です。これにより、ユーザーは一度 username とパスワードで認証されると、トークンを受け取り、それ以降はそのトークンを使用できるようになります。トークンには有効期間があります。JSON Web Tokens (JWTs) は、JSON Web Token Standard に準拠したトークンであり、claims の形式で ID に関する情報を含みます。これらは自己完結型であるため、受信者がトークンを検証するためにサーバーへ問い合わせる必要はありません。JWT は、secret (HMAC アルゴリズムを使用) または RSA を使用する公開鍵／秘密鍵のキーペアで署名できます。JWT の詳細については、こちらを参照してください。JWT である IDトークン は、業界標準 (IETF RFC 7519) に準拠しており、3 つの部分で構成されます。ヘッダー、ボディ、署名です。
  • ヘッダーには、トークンの種類と、トークンの内容に使用されるハッシュアルゴリズムが含まれます。
  • ボディはペイロードとも呼ばれ、ユーザーに関する ID claims を含みます。登録済みの名前を持つ claim には、トークンの発行者、トークンの subject (claims の対象) 、発行時刻などがあります。その他の名前を持つ追加の claims はいくつでも追加できますが、JWT が URL におけるブラウザーのサイズ制限内に収まるよう注意が必要です。
  • 署名は、JWT の受信者が JWT に含まれる情報の完全性を検証するために使用されます。

​
IDトークンを検証する方法

IDトークンの検証には、複数の手順が必要です。
  1. IDトークンが暗号化されている場合は、アプリケーションが指定した鍵とアルゴリズムを使用して復号します。
  2. OpenIDプロバイダーの Issuer 識別子は、iss (issuer) クレームの値と一致している必要があります。
  3. aud (audience) クレームには、アプリケーションの client_id 値が含まれている必要があります。IDトークンにアプリケーションが有効なオーディエンスとして含まれていない場合、またはアプリケーションが信頼していない追加のオーディエンスが含まれている場合、その IDトークンは拒否する必要があります。
  4. IDトークンに複数のオーディエンスが含まれている場合、アプリケーションは azp クレームが存在することを確認する必要があります。
  5. azp (authorized party) クレームが存在する場合、アプリケーションはその値が自身の client_id と一致することを確認する必要があります。
  6. アプリケーションは、JWT の alg ヘッダーパラメーターで指定されたアルゴリズムを使用し、JWS に従って IDトークンの署名を検証する必要があります。アプリケーションは Issuer が提供する鍵を使用する必要があります。
  7. alg の値は、デフォルトの RS256、または登録時にアプリケーションが id_token_signed_response_alg パラメーターで送信したアルゴリズムである必要があります。
  8. JWT の alg ヘッダーパラメーターで HS256、HS384、HS512 などの MAC ベースのアルゴリズムを使用する場合、aud (audience) クレームに含まれる client_id に対応する client_secret の UTF-8 表現のオクテット列が、署名検証の鍵として使用されます。MAC ベースのアルゴリズムでは、aud が複数の値を持つ場合、または aud の値と異なる azp 値が存在する場合の動作は規定されていません。
  9. 現在時刻は、exp クレームが示す時刻より前でなければなりません。
  10. iat クレームは、現在時刻から大きく外れた時刻に発行されたトークンを拒否するために使用できます。これにより、攻撃を防ぐために nonce を保存しておく必要がある期間を制限できます。許容範囲はアプリケーションごとに異なります。
  11. 認証リクエストで nonce 値が送信された場合は、nonce クレームが存在し、その値が認証リクエストで送信された値と同一であることを確認する必要があります。アプリケーションは、リプレイ攻撃に対して nonce 値を確認する必要があります。リプレイ攻撃を検出する具体的な方法は、アプリケーションごとに異なります。
  12. acr クレームが要求された場合、アプリケーションは提示されたクレーム値が適切であることを確認する必要があります。
  13. auth_time クレームが、このクレームの明示的な要求、または max_age パラメーターの使用によって要求された場合、アプリケーションは auth_time クレームの値を確認し、最後のエンドユーザー認証から長時間が経過していると判断した場合は再認証を要求する必要があります。
IDトークンをサーバーに保存する場合は、必ず安全に保管してください。