Skip to main content
このセクションでは、実装するソリューションの概要として、アイデンティティ管理の詳細、使用するプロトコル、必要となる認証フローについて説明します。

​
アイデンティティ管理

ExampleCo は、Identity as a Service (IDaaS) プロバイダーとして Auth0 を採用することにしました。その理由は、アイデンティティ管理とアクセス管理のトレーニング、導入、運用保守に自社のリソースを割きたくなかったためです。さらに同社は今後、このソリューションを拡張し、モバイル向けネイティブアプリや、承認済みのタイムシートを社内システムに送信する API を追加する可能性も視野に入れています。Auth0 は、このような変更を最小限の労力でアーキテクチャに組み込める柔軟性を備えています。
Identity-as-a-Service (「IDaaS」) は、アイデンティティ管理とアクセス管理のためのクラウドベースのサービスです。提供されるサービスには、通常、シングルサインオン (SSO) 、フェデレーション、パスワード管理などが含まれます。

​
どのプロトコルを使うか

次に決めるべきなのは、どのプロトコルを使うかです。 と 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 にリダイレクトし、Dropbox はその Web サイトにファイルへのアクセスを許可してよいかどうかを確認します。あなたが同意すれば、その Web サイトは Dropbox 上のファイルにアクセスする権限を得ます。要するに、OAuth 2.0 はリソースへのアクセスと共有のためのものです。 OpenID Connect は、一方で、OAuth 2.0 プロトコルの上に構築されたシンプルな ID レイヤーです。これにより、複数のサイトで 1 つのログインを使えます。OIDC を使って Web サイトにログインする必要があるたびに、OpenID サイトへリダイレクトされ、そこでログインしたあと元の Web サイトに戻ります。要するに、OIDC が扱うのはユーザー認証です。
SAML は XML ベースのプロトコルで、信頼関係のある当事者間で認証と認可の両方を提供します。 SAML と比べると、OpenID Connect はより軽量で扱いやすく、シンプルです。SAML は実績があり、強力で柔軟ですが、このアプリの要件ではそうした柔軟性や強力さは必要ありません。SAML を採用する大きな理由の 1 つである ID フェデレーションも、ここでは必要ありません。さらに、仮に将来それが要件になったとしても、Auth0 なら AD (LDAP を使用) を扱うのと同じように簡単に対応できます。 これらの理由から、ExampleCo は実装に OpenID Connect を使用します。

​
認証フロー

OpenID Connect では、認証に複数のフローを利用できます。ここでは一般的な Web アプリのシナリオを扱うため、Authorization Code Flow を使用します。 フローは次のとおりです。
  1. Web アプリ (OIDC の用語では Client) は、ユーザーエージェント (ブラウザー) を Auth0 (OIDC の用語では Authorization Server) にリダイレクトして、認証リクエストを開始します。
  2. Auth0 は (ユーザーエージェント経由で) ユーザーを認証します。ユーザーが初めてこのフローを実行する場合は、アプリケーションに付与される権限 (たとえば、メッセージの投稿や連絡先の一覧表示) が示された同意画面が表示されます。ユーザーはサービスにログインし (まだログインしていない場合) 、アプリケーションへのアクセスを承認します。
  3. ユーザーがアクセスを許可すると、Auth0 はクエリー文字列に認可コードを付与して、ユーザーエージェントをアプリケーションにリダイレクトします。
  4. アプリケーションは認可コードとアプリケーションの認証情報 (client_id と client_secret) を Auth0 に送信し、トークンを要求します。
  5. Auth0 はアプリケーションを認証し (client_id と client_secret を使用) 、認可コードを検証します。有効であれば、Auth0 は ID Token を返します。
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 Token が直接含まれます。一方、response_mode=form_post では、ID Token と残りの Authorization Response パラメーターが HTML フォームの値としてエンコードされ、User Agent で自動送信されます。この方法を使うと、認可コードを ID Token に交換する必要がないため、認証フローを最適化できます。ただし、アプリの実装に使用している技術がこれをサポートしている必要があります (ASP .NET Core middleware はサポートしています) 。詳しくは、OAuth 2.0 Form Post Response Mode specification を参照してください。
ID Token (コードサンプルでは通常 id_token と表記されます) は、ID 情報を含む JSON Web Token (JWT) です。アプリケーションはこれを利用して、ユーザー名やメールアドレスなどのユーザー情報を取得し、通常は UI に表示します。

​
トークンについてさらに詳しく

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

​
ID Token を検証する方法

ID Token の検証には、いくつかの手順が必要です。
  1. ID Token が暗号化されている場合は、アプリケーションが指定した鍵とアルゴリズムを使用して復号します。
  2. OpenID Provider の Issuer Identifier は、iss (issuer) クレームの値と一致している必要があります。
  3. aud (audience) クレームには、アプリケーションの client_id 値が含まれている必要があります。ID Token にアプリケーションが有効な audience として記載されていない場合、またはアプリケーションが信頼していない別の audience が含まれている場合は、その ID Token を拒否しなければなりません。
  4. ID Token に複数の audience が含まれている場合、アプリケーションは azp クレームが存在することを確認する必要があります。
  5. azp (authorized party) クレームが存在する場合、アプリケーションは、その値が自身の client_id であることを確認する必要があります。
  6. アプリケーションは、JWT の alg ヘッダーパラメータで指定されたアルゴリズムを使用し、JWS に従って ID Token の署名を検証しなければなりません。アプリケーションは、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. Authentication Request で nonce 値が送信されていた場合は、nonce クレームが存在し、その値が Authentication Request で送信された値と同一であることを確認する必要があります。アプリケーションは、リプレイ攻撃に対して nonce 値を確認する必要があります。リプレイ攻撃を検出する具体的な方法は、アプリケーションごとに異なります。
  12. acr クレームが要求されていた場合、アプリケーションは、表明されたクレーム値が適切であることを確認する必要があります。
  13. auth_time クレームが、このクレームに対する明示的な要求または max_age パラメータの使用によって要求されていた場合、アプリケーションは auth_time クレーム値を確認し、最後の End-User 認証から長時間が経過していると判断した場合は、再認証を要求する必要があります。
ID Token をサーバーに保存する場合は、必ず安全に保存してください。