付与タイプ¶

付与タイプは、クライアントがIdentityServerとやり取りする方法を指定する方法です。OpenID ConnectとOAuth 2の仕様では、以下の付与タイプが定義されています。

Implicit
Authorization code
Hybrid
Client credentials
Resource owner password
Device flow
Refresh tokens
Extension grants

構成AllowedGrantTypes上のプロパティーを使用して、クライアントが使用できる許可タイプを指定できますClient。

クライアントは、2つ以上の認可タイプを使用するように構成できます（たとえば、ユーザー中心の操作の場合はハイブリッド、サーバー間の通信の場合はクライアント資格情報）。 GrantTypes このクラスは、典型的な補助金型の組み合わせから選択するために使用することができます。

Client.AllowedGrantTypes = GrantTypes.HybridAndClientCredentials;

許可タイプリストを手動で指定することもできます。

Client.AllowedGrantTypes =
{
    GrantType.Hybrid,
    GrantType.ClientCredentials,
    "my_custom_grant_type"
};

ブラウザのチャンネルを介してアクセストークンを送信する場合は、クライアントの設定で明示的に許可する必要があります。

Client.AllowAccessTokensViaBrowser = true;

注釈

セキュリティ上の理由から、すべての許可タイプの組み合わせが許可されるわけではありません。詳細は以下を参照してください。

残りの部分については、助成金の種類について簡単に説明し、使用する時期についても説明します。また、相違点の理解を深めるために、対応する仕様を読むことをお勧めします。

Client credentials¶

これは最も単純なグラント・タイプであり、サーバー間の通信に使用されます。トークンは、ユーザーではなくクライアントのために常に要求されます。

この許可タイプでは、トークン要求をトークンエンドポイントに送信し、クライアントを表すアクセストークンバックを取得します。クライアントは通常、クライアントIDと秘密情報を使用してトークンエンドポイントで認証する必要があります。

使用方法のサンプルについては、クライアントクレデンシャルのクイックスタートを参照してください。

Resource owner password¶

リソース所有者のパスワード付与タイプを使用すると、ユーザーの名前とパスワードをトークンエンドポイントに送信することによって、ユーザーの代わりにトークンを要求できます。これは「非対話型」認証と呼ばれ、一般的には推奨されません。

特定のレガシーまたはファーストパーティの統合シナリオには、このグラントタイプが便利な理由があるかもしれませんが、代わりにユーザー認証のために暗黙またはハイブリッドのような対話型フローを使用することが推奨されます。

See the Resource Owner Password Quick Start for a sample how to use it. You also need to provide code for the username/password validation which can be supplied by implementing the IResourceOwnerPasswordValidator interface. You can find more information about this interface here.

Implicit¶

The implicit grant type is optimized for browser-based applications. Either for user authentication-only (both server-side and JavaScript applications), or authentication and access token requests (JavaScript applications).

In the implicit flow, all tokens are transmitted via the browser, and advanced features like refresh tokens are thus not allowed.

This quickstart shows authentication for service-side web apps, and this shows JavaScript.

Authorization code¶

Authorization code flow was originally specified by OAuth 2, and provides a way to retrieve tokens on a back-channel as opposed to the browser front-channel. It also support client authentication.

While this grant type is supported on its own, it is generally recommended you combine that with identity tokens which turns it into the so called hybrid flow. Hybrid flow gives you important extra features like signed protocol responses.

Hybrid¶

Hybrid flow is a combination of the implicit and authorization code flow - it uses combinations of multiple grant types, most typically code id_token.

In hybrid flow the identity token is transmitted via the browser channel and contains the signed protocol response along with signatures for other artifacts like the authorization code. This mitigates a number of attacks that apply to the browser channel. After successful validation of the response, the back-channel is used to retrieve the access and refresh token.

This is the recommended flow for native applications that want to retrieve access tokens (and possibly refresh tokens as well) and is used for server-side web applications and native desktop/mobile applications.

See this quickstart for more information about using hybrid flow with MVC.

Device flow¶

Device flow is designed for browserless and input constrained devices, where the device is unable to securely capture user credentials. This flow outsources user authentication and consent to an external device (e.g. a smart phone).

This flow is typically used by IoT devices and can request both identity and API resources.

Refresh tokens¶

Refresh tokens allow gaining long lived access to APIs.

You typically want to keep the lifetime of access tokens as short as possible, but at the same time don't want to bother the user over and over again with doing a front-channel roundtrips to IdentityServer for requesting new ones.

Refresh tokens allow requesting new access tokens without user interaction. Every time the client refreshes a token it needs to make an (authenticated) back-channel call to IdentityServer. This allows checking if the refresh token is still valid, or has been revoked in the meantime.

Refresh tokens are supported in hybrid, authorization code, device flow and resource owner password flows. To request a refresh token, the client needs to include the offline_access scope in the token request (and must be authorized to request for that scope).

Extension grants¶

Extension grants allow extending the token endpoint with new grant types. See this for more details.

Incompatible grant types¶

Some grant type combinations are forbidden:

Mixing implicit and authorization code or hybrid would allow a downgrade attack from the more secure code based flow to implicit.
Same concern exists for allowing both authorization code and hybrid