Difference between revisions of "Authorization Code flow description"

From i2Rest
Jump to: navigation, search
Line 8: Line 8:
 
(А) Клиент обращается к I2Rest Server c Client ID, scopes,  
 
(А) Клиент обращается к I2Rest Server c Client ID, scopes,  
  
(A)  The client initiates the flow by directing the resource owner'suser-agent to the authorization endpoint.  The client includes
+
(D)  The client initiates the flow by directing the resource owner'suser-agent to the authorization endpoint.  The client includes
 
         its client identifier, requested scope, local state, and a
 
         its client identifier, requested scope, local state, and a
 
         redirection URI to which the authorization server will send the
 
         redirection URI to which the authorization server will send the
 
         user-agent back once access is granted (or denied).
 
         user-agent back once access is granted (or denied).
  
  (B)  The authorization server authenticates the resource owner (via
+
(F)  The authorization server authenticates the resource owner (via
 
         the user-agent) and establishes whether the resource owner
 
         the user-agent) and establishes whether the resource owner
 
         grants or denies the client's access request.
 
         grants or denies the client's access request.
  
  (C)  Assuming the resource owner grants access, the authorization
+
(G)  Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the
        server redirects the user-agent back to the client using the
+
redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state
        redirection URI provided earlier (in the request or during
+
provided by the client earlier.
        client registration). The redirection URI includes an
 
        authorization code and any local state provided by the client
 
        earlier.
 
  
  (D) The client requests an access token from the authorization
+
(I) The client requests an access token from the authorization server's token endpoint by including the authorization code
        server's token endpoint by including the authorization code
+
received in the previous step.  When making the request, the client authenticates with the authorization server. The client
        received in the previous step.  When making the request, the
+
includes the redirection URI used to obtain the authorization code for verification.
        client authenticates with the authorization server. The client
 
        includes the redirection URI used to obtain the authorization
 
        code for verification.
 
  
  (E) The authorization server authenticates the client, validates the
+
(J) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI
        authorization code, and ensures that the redirection URI
+
received matches the URI used to redirect the client in step (C).  If valid, the authorization server responds back with
        received matches the URI used to redirect the client in
+
an access token and, optionally, a refresh token.
        step (C).  If valid, the authorization server responds back with
 
        an access token and, optionally, a refresh token.
 
 
----
 
----
 
[[I2Rest_Client|Back to i2Rest Client]]
 
[[I2Rest_Client|Back to i2Rest Client]]

Revision as of 14:18, 26 May 2020

The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, I2Rest Client can't deal with it. The problem is that i2Rest Client is not capable of receiving incoming requests via redirection and have no ability to display authorization page. But both problems can be solved using i2Rest Server as a "bridge" between I2Rest Client and authorization server. Lets take a look on scheme.
There is not much diferencies - we just have to implement "i2rest server bridges" to solve IBM i functional limitations. Bridge flow scheme.png

The flow illustrated in Figure 3 includes the following steps: Шаги A Б Ц Д - организация обращения к серверу авторизации от i2resr server вместо i2rest client с целью поддержки переадресации на страницу авторизации. (А) Клиент обращается к I2Rest Server c Client ID, scopes,

(D) The client initiates the flow by directing the resource owner'suser-agent to the authorization endpoint. The client includes

       its client identifier, requested scope, local state, and a
       redirection URI to which the authorization server will send the
       user-agent back once access is granted (or denied).

(F) The authorization server authenticates the resource owner (via

       the user-agent) and establishes whether the resource owner
       grants or denies the client's access request.

(G) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.

(I) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.

(J) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.


Back to i2Rest Client