Difference between revisions of "Authorization Code flow description"
Pavel.lobko (talk | contribs) |
Pavel.lobko (talk | contribs) |
||
Line 1: | Line 1: | ||
{{DISPLAYTITLE:Authorization Code flow using i2Rest bridge mode description}} | {{DISPLAYTITLE:Authorization Code flow using i2Rest bridge mode description}} | ||
− | Authorization Code flow using i2Rest bridge | + | Authorization Code flow using i2Rest bridge has not too much diferencies from [https://tools.ietf.org/html/rfc6749#section-4.1 original Authorization Code flow] - we just have to implement two "bridges" to solve next IBM i functional limitations: |
− | + | ||
+ | - i2Rest Client is not capable of interacting with the resource owner's user-agent (typically a web browser), this functions are delegated to the i2Rest Server. To perform the delegation i2Rest Client have to provide i2Rest Server with all the necessery request detailы and bring the end user's agent to Bridge endpoint. This process is described in steps A-B-C. | ||
+ | - i2Rest Client also is not capable of receiving incoming requests via redirection, so I2Rest Server have to receive | ||
+ | Lets take a look on scheme.<br> | ||
[[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: | ||
− | + | With steps A-C i2Rest Client is not capable of interacting with the resource owner's user-agent (typically a web browser), this functions sre delegated the communications with authorization server to the i2Rest Server. I2 | |
− | ( | + | |
+ | |||
+ | (А) i2Rest Client initiates the flow with a request to the I2Rest Server Bridge endpoint. The request incudes client identifier, requested scope and Authorization server URL. | ||
+ | |||
+ | (B) I2Rest Server responds with Brigde URL, Bridge User Code and Bridge Code. | ||
+ | |||
+ | (C) i2Rest Client instructs the user to visit provided Brigde URL using device with input capability and browser support. Now I2Rest | ||
(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). | (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). |
Revision as of 14:42, 27 May 2020
Authorization Code flow using i2Rest bridge has not too much diferencies from original Authorization Code flow - we just have to implement two "bridges" to solve next IBM i functional limitations:
- i2Rest Client is not capable of interacting with the resource owner's user-agent (typically a web browser), this functions are delegated to the i2Rest Server. To perform the delegation i2Rest Client have to provide i2Rest Server with all the necessery request detailы and bring the end user's agent to Bridge endpoint. This process is described in steps A-B-C.
- i2Rest Client also is not capable of receiving incoming requests via redirection, so I2Rest Server have to receive
Lets take a look on scheme.
The flow illustrated in Figure 3 includes the following steps: With steps A-C i2Rest Client is not capable of interacting with the resource owner's user-agent (typically a web browser), this functions sre delegated the communications with authorization server to the i2Rest Server. I2
(А) i2Rest Client initiates the flow with a request to the I2Rest Server Bridge endpoint. The request incudes client identifier, requested scope and Authorization server URL.
(B) I2Rest Server responds with Brigde URL, Bridge User Code and Bridge Code.
(C) i2Rest Client instructs the user to visit provided Brigde URL using device with input capability and browser support. Now I2Rest
(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.
Parameter | Description |
---|---|
Authentication method | *OAUTH2C must be specified
|
Command | Any of available request type can be choosen |
API endpoint | HTTP resource to serve the request |
Tokens storage | ??????? |
User/OAuth2 client/device ID | Client Credentials to authenticate with authorization server |
User/OAuth2 client/dev passwd | |
OAuth2 token endpoint | HTTP resource used by the client to abtain an access token |
Scope | the set of resources and operations that are allowed to application with access token |