With this post, I want to open a thread of articles dedicated to IdentityServer4. Let's start with the basic concepts.
The most promising authentication protocol at the moment is , and the authorization (access) protocol is . implements these two protocols. It is optimized to solve typical problems security.
is an authentication protocol and standard, it does not provide access to resources (Web API), but since it is designed on top of the authorization protocol , it allows you to get the user profile settings as if you accessed the resource .
(JSON Web Token) is a web standard that defines how user data is transmitted in JSON format in encrypted form.
is a protocol and authorization standard. It allows applications to access protected resources such as Web APIs.
Let's take a look at the diagram of accessing a protected resource and understand the main steps and the accepted terminology:
The client asks the user for permission to authenticate on their behalf. Customer is a client application accessing protected resources on behalf of the resource owner. Resource - these are all our secure services .
User allows the client application to pass authorization on its behalf, for example, enters a username and password. The login and password will be the authorization grant for the client application. User (resource owner) - a program or a person who can give access to protected resources, for example, by entering a login (username) and a password (password);
The client application requests an access token from
IdentityServer4by providing information about yourselfclient_id,client_secret), granting authorization permission from the user (username,password) and providinggrant_typeиscope. Then the authorization server authenticates the client and the details of the resource owner (login and password).The OAuth 2.0 protocol authenticates not only the user, but also the client application accessing resources. To do this, the protocol provides such parameters as client_id и client_secret.
client_id is the client application ID usedIdentityServer4to search for customer information.
client_secret is an analogue of the password for the client application and is used to authenticate the client application onIdentityServer4. The client secret should only be known to the application and the API. Based on the above, we conclude that IdentityServer4 needs to know about its clients.If the authenticity of the application is confirmed and the authorization permission is valid,
IdentiryServer4createsaccess-токен(access token) for the app and an optional refresh key (refresh-токен). The authorization process has been completed. If the request is invalid or unauthorized, then the authorization server returns a code with an appropriate error message.The client application requests data from a secure Web API, while providing an access token for authorization. If the resource server response code , or , then the access token used for authentication is invalid or expired.
If the token is valid,
Web APIprovides data to the application.
Token types
Registered in IdentityServer4 customers are allowed to request IdentityServer4 identity-token, access-token and refresh-token.
- identity-token (identification token) - the result of the authentication process. Contains the user ID and information about how and when the user is authenticated. You can expand your data.
- access-token (access token) - transmitted to a secure API and used by them to authorize (permit access) to their data.
- refresh-token (refresh token) is an optional parameter that the authorization server can return in response to an access token request.
Let's introduce two more concepts:
Authentication Server Url - Endpoint to get the access token. All requests to provide and renew access keys will be sent to this URL.
Resource Url — The URL of the protected resource to be accessed in order to access it, passing it the access key in the authorization header.
Access key request
To request an access key, the client does POST endpoint request IdentityServer4 with the following heading
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'and passing the following parameters:
'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'username, password, client_id и client_secret have been disassembled above. Let's look at the rest of the options:
grant_type — grant type or authorization permission type. The authorization permission type depends on the method used by the application to request authorization, as well as which permission types are supported by the API. In our case, it will matter password, which according to the specification OAuth 2.0 corresponds to the access details grant of the resource owner (authorization by login and password).
Protocol OAuth 2.0 defines the following types of grants requiring mandatory interaction with users:
- authorization code. It is one of the most common types of authorization permission, because well suited for server-side applications where the application source code and client secret are not available to outsiders;
- implicit. The implicit authorization permission type is used by mobile and web applications where the confidentiality of the client secret cannot be guaranteed;
And the types of grants that can be executed without interactive interaction with users:
- resource owner details. This type of permission should only be used if the client application is trusted by the user and the user is comfortable entering their username and password. This permission type should only be used when no other options are available. This type of permission is useful for corporate customers who have already used user credentials within their system and want to switch to
OAuth 2.0. - client credentials. Used when the application accesses the API. This can be useful, for example, when an application wants to update its own service registration information or redirect URI, or access other information stored in the application's service account through the service's API.
scope is an optional parameter. It defines the scope. The access token returned by the server will only allow access to services within that scope. Those. we can combine several services under one scope and if the client receives an access key to this scope, he gets access to all these services. Also scope can be used to restrict authorization rights (for example, read or write access)
Source: habr.com
