アクセス トークンの発行に加えて、許可サーバーは、関連する管理サービスも提供します。これは通常、Webユーザー インターフェイスを介して行われます。たとえば、次のようなことを定義したり管理したりできます。

ONTAPは、OAuth 2.0標準に準拠した許可サーバーと互換性があります。

1台以上の許可サーバーをONTAPに定義する必要があります。ONTAPは、各サーバーとのセキュアーな通信を通じてトークンを検証したり、その他の関連タスクを実行したりして、クライアント アプリケーションを支援します。

ここでは、ONTAPの設定の主な側面について解説します。詳細については、「OAuth 2.0の導入シナリオ」も参照してください。

アクセス トークンの検証には、2つのオプションがあります。

ONTAPは、ファイアウォールの内側にある可能性があります。この場合は、設定の際にプロキシを指定する必要があります。

ONTAPに許可サーバーを定義する際には、CLI、ONTAP System Manager、REST APIなど任意の管理インターフェイスを使用できます。たとえば、CLIではsecurity oauth2 client createコマンドを使用します。

1つのONTAPクラスタに対して、最大8台の許可サーバーを定義できます。発行者または発行者 / オーディエンスのクレームが一意である限り、同じ許可サーバーを同じONTAPクラスタに複数回定義できます。たとえば、Keycloakで異なるRealmを使用する場合は、常にこれが該当します。

アクセス トークンは、REST APIを使用するONTAPクラスタに定義されている許可サーバーから取得する必要があります。トークンを取得するには、許可サーバーと直接やり取りする必要があります。

トークンを要求する方法は、次のようないくつかの要因によって異なります。

グラントとは、OAuth 2.0アクセス トークンの要求と受領に使用される明確に定義されたプロセスです。一連のネットワーク フローもこれに含まれます。クライアント、環境、セキュリティの要件に応じて、さまざまなグラント タイプを使用できます。次の表は、よく利用されるグラント タイプをまとめたものです。

OAuth 2.0アクセス トークンは、JWT形式です。そのコンテンツは、設定に基づいて許可サーバーによって作成されます。ただし、クライアント アプリケーションはトークンを解読できません。クライアントには、トークンを検査したり、そのコンテンツを認識したりする理由がありません。

各JWTアクセス トークンには、一連のクレームが格納されています。クレームには、許可サーバーの管理定義に基づいて発行者と許可の特性が記述されています。次の表は、標準に登録されているクレームの一部をまとめたものです。すべての文字列で、大文字と小文字が区別されます。

詳細については、RFC 7519：『JSON Web Token』を参照してください。