従来の認証方法では、クライアントはユーザー名とパスワードを使用して認証することにより、サーバ上の保護されたリソースを要求します。サードパーティのアプリケーションに制限付きリソースへのアクセスを提供するために、リソース所有者は認証情報をサードパーティと共有します。
制限事項は次のとおりです。
サードパーティのアプリケーションは、後で使用するために認証情報(通常はクリア テキストのパスワード)を保存します。
パスワードに固有のセキュリティ上の弱点があるにもかかわらず、サーバはパスワード認証をサポートする必要があります。
サードパーティのアプリケーションが侵害されると、エンドユーザーのパスワードと、そのパスワードで保護されているすべてのデータが侵害されます。
OAuth
OAuth は、認証レイヤーを導入することでこのような問題に対処します。OAuth 2.0 は、リソースへの安全なアクセス権をアプリケーションに付与するための認証プロトコルです。クライアントは、Access Token を介して認証されます。アクセス トークンには、トークンがアクセスできるリソースを定義するスコープがあります。OAuth 2.0 の詳細については、「OAuth の仕様」を参照してください。
新しいアプリケーションにサインアップするときに、携帯電話または Facebook の連絡先を使用して新しい連絡先を自動的に送信元に設定することを許可している場合は、OAuth 2.0 を使用していることになります。
OAuth は、ユーザーが認証情報を共有しなくても、アプリケーションがユーザーに代わってアクションを実行したりサーバからリソースにアクセスしたりできる、安全な委任アクセスを提供します。これは、ID プロバイダ (IdP) がユーザーの承認を得てサードパーティのアプリケーションにトークンを発行できるようにすることで実現されます。
OIDC
OpenID Connect 1.0 は、OAuth 2.0 プロトコル上の単純な ID レイヤーです。これにより、クライアントは、認可サーバによって実行された認証に基づいてエンド ユーザーの ID を確認し、相互運用可能で REST のような方法でエンド ユーザーに関する基本プロファイル情報を取得することができます。詳細については、「OpenID Connect へようこそ」を参照してください。
YouTube、Jira、ショッピング カートなどのアプリケーションにサインアップするときは、よく知られている認可サーバ/IdP(Google、Facebook など)でログインを続行するオプションが表示されます。
Google などの IdP は Open ID を使用するため、ユーザーは、ログインしたりログイン情報を共有したりすることなく、IdP にログインして他の Web サイトやアプリケーションにアクセスできます。
OAuth と OIDC で使用される用語
- リソース所有者:
-
保護されたリソースへのアクセス権を付与できるユーザーまたはシステム。
- クライアント:
-
リソース所有者の承認を得てリソース所有者の代わりに保護されたリソースの要求を行うアプリケーション。
- リソース サーバ:
-
保護されたリソースをホストし、アクセス トークンを検証した後、アクセス トークンを使用して保護されたリソース要求を受け入れて応答するサーバ。
- 認可サーバ:
-
リソース所有者を正常に認証した後にクライアント アプリケーションにアクセス トークンを発行するサーバ。
- クライアント ID:
-
これは、認可サーバに登録されたアプリケーションに認可サーバが割り当てる一意の識別子です。
- クライアント シークレット:
-
これは、アプリケーションと認可サーバにのみに知られるシークレットです。
- 認可コード:
-
認可コードは、認可サーバがクライアントに発行する一時的なコードです。クライアントは、後続の要求で認可コードをアクセス トークンと交換します。
OAuth ロール
OAuth ロールは次のとおりです。
リソース所有者
リソース サーバ
クライアント
認可サーバ
NSX Advanced Load Balancer は、クライアントおよびリソース サーバのロールをサポートします。
NSX Advanced Load Balancer は、クライアントまたはリソース サーバとして機能することはできません。クライアントおよびリソース サーバとして機能できます。クライアントおよびリソース サーバである NSX Advanced Load Balancer は、エンド ユーザーから認可コードを取得してアクセス トークンと交換し、アクセス トークンを検証し、クライアントがトークン検証と、要求に基づく認可ポリシーに基づいてリソースにアクセスできるようにします。
認可取得のための OAuth 付与
OAuth 2.0 認可フレームワークは、いくつかの異なるフロー(または付与)をサポートします。フローは、アクセス トークンを取得する方法です。アクセス トークンを要求するために、クライアントはリソース所有者から認可を取得します。認可は、クライアントがアクセス トークンを要求するために使用する認可付与の形式で表されます。
OAuth は、次の 4 つの付与タイプを定義します。
認可コード
暗黙
リソース所有者のパスワード認証情報
クライアントの認証情報
NSX Advanced Load Balancer では、認可コード付与フローのみがサポートされます。
認証コード付与フロー
認可コード付与タイプのフローは次のとおりです。
リソース所有者はアプリケーション/クライアントにアクセスし、認証と認可をトリガします。
クライアントは、ユーザー名とパスワードの入力を求める認可サーバにユーザーをリダイレクトします。このページでは、リソース所有者は、クライアントがリソース所有者に代わってリソースにアクセスすることを許可する権限を選択できます。
認可サーバは認証および認可付与を受け取ります。
リソース所有者がアプリケーションを許可すると、認可サーバはリダイレクトを使用して認可コードをクライアントに送信します。
クライアントは認可コードを使用して、認可サーバからアクセス トークンを要求します。
認可サーバは認可コードを検証し、アクセス トークンを発行します。OIDC が有効になっている場合、アクセス トークンとともに ID トークンも発行されます。
クライアントは、アクセス トークンを提示して、リソース サーバからリソースにアクセスしようとします。
[アクセス トークン] が有効な場合、リソース サーバはユーザーがクライアントに受信を許可したリソースを返します。
さまざまなタイプのトークン
アクセス トークン:アクセス トークンは、保護されたリソースにアクセスするために使用される認証情報です。アクセス トークンは、クライアントに発行された認可を表す文字列です。アクセス トークンには、JSON Web トークン (JWT) や不透明トークンなどの 2 つのタイプがあります。JWT の場合、リソース サーバはアクセス トークンを独自に検証できますが、不透明トークンの場合、リソース サーバはイントロスペクション エンドポイント上の認可サーバと通信してアクセス トークンを検証します。
更新トークン:更新トークンは、認可サーバによってクライアントに発行され、現在のアクセス トークンが無効になったり期限切れになった場合に、認可サーバから新しいアクセス トークンを取得するために使用されます。次のフロー図は、期限切れのアクセス トークンがどのように更新されるかを示しています。
ID トークン:これは、クライアントで OIDC が有効になっている場合に使用されます。このトークンは認可サーバによって返され、ユーザーの認証情報をエンコードします。
さまざまなタイプのエンドポイント
- 認可/認可エンドポイント:
-
このエンドポイントは、user-agent リダイレクトを通じてリソース所有者から認可を取得するためにクライアントが使用します。
- トークン エンドポイント:
-
このエンドポイントは、認可付与をアクセス トークンと交換するためにクライアントが使用します。OIDC の場合、同じエンドポイントを使用して更新トークンと ID トークンを取得します。
- リダイレクト エンドポイント/リダイレクト URL/コールバック URL:
-
これは、リソース所有者の user-agent を経由して認可認証情報を含んでいる応答をクライアントに返すために認可サーバが使用します。これは通常 Call back URL と呼ばれます。
- イントロスペクション エンドポイント:
-
イントロスペクション エンドポイントは、不透明アクセス トークンの検証に使用されます。不透明アクセス トークンの場合、リソース サーバは認可サーバのイントロスペクション エンドポイントに要求を送信して、アクセス トークンを検証します。
- UserInfo エンドポイント:
-
UserInfo エンドポイントを使用して、ユーザーに関する ID 情報を取得できます。これは OIDC の場合に使用されます。エンド ユーザーに関してリクエストされた要求を取得するために、クライアントは取得したアクセス トークンを使用して UserInfo エンドポイントに要求します。
機密ログ プロファイル構成の非表示
[基本認可] などの OAuth の機密フィールドは、機密ログ プロファイルを使用してマスキングできます。
OAuth ログで機密情報を構成する手順は次のとおりです。
| sensitive_log_profile | | | header_field_rules[1] | | | name | Rule 1 | | index | 1 | | enabled | False | | match | | | match_criteria | CONTAINS | | match_str[1] | Authorization | | action | LOG_FIELD_MASKOFF |