Difference between revisions of "Authorization Code flow description"
Pavel.lobko (talk | contribs) |
Pavel.lobko (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | {{DISPLAYTITLE: | + | {{DISPLAYTITLE:Authorization Code flow using i2Rest bridge mode description}} |
| − | + | Authorization Code flow using i2Rest bridge both problems can be solved using i2Rest Server as a "bridge" between I2Rest Client and authorization server. Lets take a look on scheme.<br> | |
There is not much diferencies - we just have to implement "i2rest server bridges" to solve IBM i functional limitations. | There is not much diferencies - we just have to implement "i2rest server bridges" to solve IBM i functional limitations. | ||
[[File:Bridge flow scheme.png|700px]] | [[File:Bridge flow scheme.png|700px]] | ||
The flow illustrated in Figure 3 includes the following steps: | The flow illustrated in Figure 3 includes the following steps: | ||
| − | + | Steps A-D are the process of - это организация процесса, в котором I2Rest Server сможет осуществить переадресацию агента пользователя к серверу авторизации, | |
(А) Клиент обращается к I2Rest Server c Client ID, scopes, | (А) Клиент обращается к 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 | + | (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 | + | (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 | (G) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the | ||
Revision as of 17:13, 26 May 2020
Authorization Code flow using i2Rest bridge 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.
The flow illustrated in Figure 3 includes the following steps: Steps A-D are the process of - это организация процесса, в котором I2Rest Server сможет осуществить переадресацию агента пользователя к серверу авторизации, (А) Клиент обращается к 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.
