{"id":71307,"date":"2020-02-24T22:18:55","date_gmt":"2020-02-24T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt"},"modified":"2020-03-03T16:14:27","modified_gmt":"2020-03-03T13:14:27","slug":"identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Key Concepts. OpenID Connect, OAuth 2.0, and JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

With this post, I want to start a series of articles dedicated to IdentityServer4. Let's begin with the fundamental concepts.<\/p>\n

<\/p>\n

The most promising authentication protocol at the moment is OpenID Connect<\/a><\/noindex>, and the authorization protocol (access granting) is OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implements these two protocols. It is optimized to address typical issues<\/strong> security gateways.<\/p>\n

<\/a><\/noindex><\/p>\n

OpenID Connect<\/a><\/noindex> \u2014 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.0<\/a><\/noindex>it allows obtaining user profile parameters as if you had accessed the resource. UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) is a web standard that defines a method for transmitting user data in JSON format in an encrypted manner.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 is an authorization protocol and standard. It allows applications to access protected resources, such as Web APIs.<\/p><\/blockquote>\n

Let's look at the diagram for accessing a protected resource and clarify the main steps and accepted terminology:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    The client requests the user\u2019s consent to authorize on their behalf. Client<\/strong> \u2014 this is a client application that accesses protected resources on behalf of the resource owner. The resource<\/strong> \u2014 these are all our protected services. Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    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)<\/strong> \u2014 is a program or person who can grant access to protected resources, for instance, by entering a username (username) and password (password);<\/p>\n

    \n<\/li>\n

  3. \n

    The client application requests an access token from IdentityServer4<\/code> by providing information about itself (client_id<\/code>, client_secret<\/code>), allowing authorization from the user (username<\/code>, password<\/code>) and providing grant_type<\/code> and scope<\/code>. Then the authorization server verifies the client\u2019s authenticity and the resource owner\u2019s credentials (username and password). <\/p>\n

    <\/p>\n

    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<\/strong> and client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 this is the identifier for the client application used IdentityServer4<\/code> to search for information about the client.
    \nclient_secret<\/strong> is analogous to a password for the client application and is used for authenticating the client application. IdentityServer4<\/code>. The client's secret should only be known by the application and the API.<\/strong>Based on the above, we conclude that IdentityServer4 must be aware of its clients.<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    If the application's authenticity is confirmed and the authorization grant is valid, IdentiryServer4<\/code> creates an access token for the application and an optional refresh token (<\/code> 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.<\/code>The client application requests data from the protected Web API, providing the access token for authorization. If the server's resource response code<\/p>\n

    \n<\/li>\n

  5. \n

    , then the access token used for authentication is invalid or expired. 401<\/a><\/noindex>, 403<\/a><\/noindex> or 498<\/a><\/noindex>If the token is valid,<\/p>\n

    \n<\/li>\n

  6. \n

    it provides data to the application. Web API<\/code> Types of tokens<\/p>\n

    \n<\/li>\n<\/ol>\n

    <\/p>\n

    Clients registered in<\/em><\/h4>\n

    <\/p>\n

    are allowed to request an IdentityServer4<\/code> -token, IdentityServer4<\/code> identity<\/code>-token, and access<\/code>-token. refresh<\/code>identity 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.<\/p>\n

    <\/p>\n