IdentityServer4. Key Concepts. OpenID Connect, OAuth 2.0, and JWT

With this post, I want to start a series of articles dedicated to IdentityServer4. Let's begin with the fundamental concepts.

The most promising authentication protocol at the moment is OpenID Connect, and the authorization protocol (access granting) is OAuth 2.0. IdentityServer4 implements these two protocols. It is optimized to address typical issues security gateways.

OpenID Connect — it is an authentication protocol and standard that does not grant access to resources (Web API), but since it is developed on top of the authorization protocol, OAuth 2.0it allows obtaining user profile parameters as if you had accessed the resource. UserInfo.

JWT (JSON Web Token) is a web standard that defines a method for transmitting user data in JSON format in an encrypted manner.

OAuth 2.0 (RFC 6749) — is an authorization protocol and standard. It allows applications to access protected resources, such as Web APIs.

Let's look at the diagram for accessing a protected resource and clarify the main steps and accepted terminology:

1. The client requests the user’s consent to authorize on their behalf. Client — this is a client application that accesses protected resources on behalf of the resource owner. The resource — these are all our protected services. Web API.

2. The user allows the client application to authorize on their behalf, for example, by entering a username and password. The username and password will serve as the authorization grant for the client application. User (resource owner) — is a program or person who can grant access to protected resources, for instance, by entering a username (username) and password (password);

3. The client application requests an access token from IdentityServer4 by providing information about itself (client_id, client_secret), allowing authorization from the user (username, password) and providing grant_type and scope. Then the authorization server verifies the client’s authenticity and the resource owner’s credentials (username and password).

   The OAuth 2.0 protocol authenticates not only the user but also the client application accessing the resources. To do this, the protocol includes parameters such as client_id and client_secret.
   client_id — this is the identifier for the client application used IdentityServer4 to search for information about the client.
   client_secret is analogous to a password for the client application and is used for authenticating the client application. IdentityServer4. The client's secret should only be known by the application and the API.Based on the above, we conclude that IdentityServer4 must be aware of its clients..

4. If the application's authenticity is confirmed and the authorization grant is valid, IdentiryServer4 creates an access token for the application and an optional refresh token ( refresh token). The authorization process is complete. If the request is invalid or unauthorized, the authorization server returns a code with an appropriate error message.The client application requests data from the protected Web API, providing the access token for authorization. If the server's resource response code

5. , then the access token used for authentication is invalid or expired. 401, 403 or 498If the token is valid,

6. it provides data to the application. Web API Types of tokens

Clients registered in

are allowed to request an IdentityServer4 -token, IdentityServer4 identity-token, and access-token. refreshidentity token is the result of the authentication process. It contains the user's identifier and information on how and when the user is authenticated. It can be extended with your own data.

• access token is sent to the protected API and used by it for authorization (granting access) to its data.
• refresh token is an optional parameter that the authorization server may return in response to the access token request.
• Let's introduce two more concepts: Authentication Server URL

is the endpoint for obtaining an access key. All requests for granting and renewing access keys will be directed to this URL.

Resource URL is the URL of the protected resource that needs to be accessed by passing the access key in the authorization header.

Access Key Request To request an access key, the client makes

a request to the endpoint

with the following header POST 'Content-Type': 'application/x-www-form-urlencoded', 'Accept': 'application/json', 'Expect': '100-continue' IdentityServer4 and passing the following parameters:

'grant_type': 'password',
'username': login,
'password': password,
'scope': 'scope',
'client_id': 'client_id',
'client_secret': '{client_secret}'

discussed above. Let's analyze the remaining parameters:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id and client_secret were discussed above. Let's go through the remaining parameters:

grant_type — grant type or authorization grant type. The authorization grant type depends on the method of authorization request used by the application, as well as the types of grants supported by the API. In our case, it will be set to password, which according to the specification OAuth 2.0 corresponds to the resource owner credentials grant (authorization by username and password).

Protocol OAuth 2.0 defines the following grant types that require mandatory interaction with users:

• authorization code. This is one of the most common authorization grant types, as it is well-suited for server-side applications, where the application's source code and client secret are not accessible to outsiders;
• implicit grant. The implicit authorization grant type is used by mobile and web applications, where the confidentiality of the client secret cannot be guaranteed;

And grant types that can be executed without interactive user interaction:

• resource owner credentials. This type of grant should only be used when the client application is trusted by the user, and the user is comfortable entering their username and password. This type of grant should only be used when other options are not available. This grant type is convenient for corporate clients who have already used user credentials within their system and want to switch to OAuth 2.0.
• client credentials. These are used when the application accesses the API. This can be useful, for example, when the application wants to update its own registration information on the service or the redirect URI, or to access other information stored in the application's account on the service via the service's API.

scope is an optional parameter. It defines the scope. The access token returned by the server will provide access only to the services that fall within this scope. In other words, we can group several services under one scope, and if a client receives an access key for this scope, they gain access to all these services. Additionally, the scope can be used to restrict authorization rights (for example, read or write access).

Source: habr.com