1. Overview
When doing integrated login in the project, Identityserver4 will be used. After viewing the official documentation of Identityserver4, you will feel that the documentation is not comprehensive and detailed enough. This is because it is based on oauth2.0 and OpenID connect technology. To understand the authorization permission types, you need to have an understanding of oauth2.0 technology, and ids4 can implement all standard authorization permission types. Several client usage scenarios are also introduced in the ids4 document. Then, combined with oauth2.0, we can fully understand the authorization type application scenario analysis.
Authorization type clients have a variety of application scenarios including: native applications, web applications, browser applications (single-page Javascript applications).
(1) Web application: The initial application scenario of the oauth client is a web application, which runs on a remote server and needs to be accessed through a web browser. The configuration and runtime status of the application are maintained by the web server. Session cookies are usually used with the browser. Stay connected. This type of application can make full use of both front-end and back-end channels. Web applications can easily and effectively use authorization codes, client credentials, or assert permission processes because browsers generally do not convert the request URL into The fragment part is sent to the server. In most cases, the implicit permission process does not apply to web applications (but the mvc client in ids4 is a web application, and the example uses the implicit permission process).
(2) Browser application: Browser application runs completely within the browser, generally using JavaScript (single page application). While the application’s code does need to be served by the web server, the code itself does not run on the server, and the web server does not maintain any runtime state of the application. This type easily uses the front-end channel to redirect the user to another page through http redirection. But using backend channels is a bit more complicated because browser applications are subject to security restrictions to prevent cross-site attacks, so such applications are suitable for the implicit permission process.
(3) Native applications: applications that run directly on the end user’s device (computer or mobile device). Applications such as console programs, mobile development, win development, etc. can easily use back-end channels to directly send http requests to the remote server. It is somewhat difficult to use the front-end channel.
1.1 oauth2.0 authorization license type
The authorization permission type specifies how the client interacts with the token service, also called the authorization flow (Oauth flow). Authorization permission types in oauth2.0 include: implicit permission type, authorization code permission type, client credential permission type, resource owner credential permission type, and assertion permission type.
1.2 ids4 license type
IdentityServer supports all oauth standard authorization types, but for common application scenarios, you really only need to know two of them (code, ClientCredentials). Reference: https://identityserver4.readthedocs.io/en/latest/topics/grant_types.html In ids4, the authorization grant type configuration is in the Client.AllowedGrantTypes attribute of the authorization server. It is a collection type, indicating that a client can support multiple License type, as follows:
public List<ClientGrantType> AllowedGrantTypes { get; set; }
The following are the license types supported by ids4:
?1.3 Communication Channel
Before understanding the authorization type, you must understand the communication channels, including: front-end channels and back-end channels. The channel here refers to the interaction between roles and components in oauth. oauth is a protocol based on http, but the interaction in oauth is not always completed through simple http requests and responses.
Backend channel: Backend channel communication means that http requests and responses use the conventional http mechanism to communicate: headers, query parameters, http methods. Similar to using httpclient to send requests. The authorization server provides an authorization endpoint/authorize for the client to request access tokens and refresh tokens. The client directly makes a request to this endpoint, carrying a set of parameters in a form format. The authorization server parses and processes these parameters, and then authorizes the server. Returns a json object representing the token.
Front-end channel: This is an indirect communication method, rather than the direct communication method of the back-end channel. It uses the web browser as a medium and uses http requests to achieve indirect communication between the two systems. Achieve cross-security domain work and information isolation (identity authentication in authorization server such as: OpenID connect). The front-end channel requires the use of a web browser and http redirection, which is a common method for interactive authentication and authorization. For example, if the enterprise network uses WeChat or Alipay to log in, it is all through the front-end channel. Since data may be tampered with using a web browser, OpenID connect requires the client or authorization server to sign the message in the front-end information, thus increasing the security mechanism.
2. License Type
2.1?Implicit
Implicit: Implicit permission type. JavaScript applications that run entirely in the browser fall into this category. They are browser-based applications that only use the front-end channel to communicate with the authorization server. The client sends a request to the authorization endpoint of the authorization server and notifies the authorization server to directly generate a token and return it. All tokens are transmitted through the browser and cannot be used to obtain refresh tokens due to the ephemeral nature of in-browser applications. This permission type assumes that the resource owner is always present and can reauthorize the client if necessary. The client response_type value is token.
As shown below: An interactive client is configured in the authorization server whitelist, using the implicit permission type.
// OpenID Connect implicit flow client (MVC)
new Client
{
ClientId = "mvc",
ClientName = "MVC Client",
AllowedGrantTypes = GrantTypes.Implicit,
// where to redirect to after login
RedirectUris = { "http://localhost:5002/signin-oidc" },
// where to redirect to after logout
PostLogoutRedirectUris = { "http://localhost:5002/signout-callback-oidc" },
AllowedScopes = new List<string>
{
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile
}
}
?2.2ClientCredentials
ClientCredentials: Client credentials permission type. This does not need to be based on a browser application. The client represents itself and can only use back-end channels, such as using the HttpClient class get or post request of the console program to communicate directly with the authorization server. This kind of client needs to provide ClientId (username) and ClientSecret (password) to obtain the access token. Refresh tokens are not issued as part of the client credential licensing process because the client can obtain a new token at any time via username and password.
As shown below: the code for the client to obtain the token:
var tokenResponse = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
{
Address = disco.TokenEndpoint,
ClientId = "client",
ClientSecret = "secret",
Scope = "api1"
});
2.3 ResourceOwnerPassword
ResourceOwnerPassword: Resource owner credential permission type. The client uses plain text username and password to send to the authorization server. The authorization server receives the request, retrieves the username and password, and compares it with the locally stored user information. If it matches, the authorization server issues a token to the client. This is called the password process. , can only communicate through the backend channel. In this password flow, the resource owner interacts directly with the client, rather than the authorization server, and the client can store the password and use it at will. If you can avoid it, don’t use it in production. This permission type should only be used as an interim solution for clients that originally asked for a username and password to log in directly and now switch to oauth. Such clients should be directed to the authorization code licensing process as soon as possible. This permission type also generates refresh tokens, providing the client with a refresh token so that it no longer needs to save the user’s password.
It looks like this: The client will somehow collect the user’s password and send it to the token service during the token request.
var tokenResponse = await client.RequestPasswordTokenAsync(new PasswordTokenRequest
{
Address = disco.TokenEndpoint,
ClientId = "ro.client",
ClientSecret = "secret",
UserName = "alice",
Password = "password",
Scope = "api1"
});
2.4 Hybrid
?Hybrid: Mixed flow license type. In the Implicit flow, all tokens are transferred through the browser, which is perfectly fine for identity tokens. Now, we also want to request an access token. Access tokens are more sensitive than identity tokens and this flow gives us the best of both worlds, the identity token is transmitted over the browser channel so the client can validate it before doing any more work. If authentication is successful, the client opens a backchannel to the token service to retrieve the access token. The client is provided with access to the offline_access scope – this allows requesting refresh tokens for long-lived API access.
As shown below: Authorization server whitelist configuration, similar to the implicit permission type, adds access to api resources.
new Client
{
ClientId = "mvc",
ClientName = "MVC Client",
AllowedGrantTypes = GrantTypes.Hybrid,
ClientSecrets =
{
new Secret("secret".Sha256())
},
RedirectUris = { "http://localhost:5002/signin-oidc" },
PostLogoutRedirectUris = { "http://localhost:5002/signout-callback-oidc" },
AllowedScopes =
{
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile,
"api1"
},
AllowOfflineAccess = true
};
Reference: https://identityserver4.readthedocs.io/en/latest/quickstarts/5_hybrid_and_api_access.htm
SaveTokens: Attribute of mvc client, set to true, then the OpenID Connect handler will automatically save the tokens in the cookie for you.
2.5 Code
Authorization code authorization code permission type. The client redirects the user agent to the authorization server endpoint, the user login page, with redirect_uri. In the identityserver4 document, the Code type is used in the javascriptp client project because ajax is used to call the api. , CORS needs to be configured in the Web API project to allow ajax access by the javascriptp client. Support refresh tokens.
(1) The front-end channel step executed through the browser, where all “interactive” things happen, such as login pages, consents, etc. This step generates an authorization code that represents the result of the front-end channel operation.
(2) The reverse channel step, where the authorization code from step 1 is exchanged with the requested token. At this point, the key client needs to authenticate.
3. Guide to choosing the right license type
