Detailed explanation of the authorization mode of the client
Authorization code mode:
The authorization code mode (authorization code) is the authorization mode with the most complete functions and the most rigorous process. Its characteristic is to interact with the authentication server of the "service provider" through the background server of the client.
Steps:
(A) The user accesses the client, which directs the former to the authentication server.
(B) The user chooses whether to authorize the client.
(C) Assuming that the user grants authorization, the authentication server directs the user to the "redirection URI" (redirection URI) specified by the client in advance, and attaches an authorization code at the same time.
(D) The client receives the authorization code, attaches the previous "redirect URI", and applies for a token to the authentication server. This step is done on the server in the background of the client and is not visible to the user.
(E) The authentication server checks the authorization code and the redirection URI, and after confirming that it is correct, sends an access token (access token) and a refresh token (refresh token) to the client.
In step A, the URI for the client to apply for authentication includes the following parameters:
response_type: Indicates the authorization type, which is required, and the value here is fixed as "code"
client_id: indicates the ID of the client, and the required item
redirect_uri: indicates the redirection URI, which can be Option
scope: Indicates the permission scope of the application, optional
state: Indicates the current state of the client, you can specify any value, and the authentication server will return this value intact.
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.comIn step C, the server responds to the URI of the client, including the following parameters:
code: Indicates the authorization code, which is required. The validity period of this code should be very short, usually set to 10 minutes, and the client can only use this code once, otherwise it will be rejected by the authorization server. There is a one-to-one correspondence between the code and the client ID and redirection URI.
state: If the client's request contains this parameter, the authentication server's response must also contain this parameter exactly.
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyzIn step D, the client requests an HTTP request for a token from the authentication server, including the following parameters:
grant_type: Indicates the authorization mode used, a mandatory item, and the value here is fixed as "authorization_code".
code: Indicates the authorization code obtained in the previous step, which is required.
redirect_uri: Indicates the redirection URI, which is mandatory and must be consistent with the parameter value in step A.
client_id: Indicates the client ID, which is required.
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
In step E, the HTTP reply sent by the authentication server includes the following parameters:
access_token: Indicates the access token, which is required.
token_type: Indicates the token type, the value is case-insensitive, required, and can be bearer type or mac type.
expires_in: Indicates the expiration time, in seconds. If this parameter is omitted, the expiration time must be set in other ways.
refresh_token: Indicates the refresh token, which is used to obtain the next access token, optional.
scope: Indicates the scope of authority, if it is consistent with the scope applied by the client, this item can be omitted.
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
As you can see from the above code, the relevant parameters are sent in JSON format (Content-Type: application/json). In addition, the HTTP header information clearly specifies that it must not be cached.
Simplified mode:
The simplified mode (implicit grant type) directly applies for a token to the authentication server in the browser without going through the server of the third-party application, skipping the step of "authorization code", hence the name. All steps are done in the browser, the token is visible to the visitor, and no authentication is required on the client side.
Steps:
(A) The client directs the user to the authentication server.
(B) The user decides whether to authorize the client.
(C) Assuming that the user grants authorization, the authentication server directs the user to the "redirect URI" specified by the client, and includes the access token in the Hash part of the URI.
(D) The browser sends a request to the resource server, which does not include the Hash value received in the previous step.
(E) The resource server returns a web page that contains code to obtain the token in the Hash value.
(F) The browser executes the script obtained in the previous step to extract the token.
(G) The browser sends the token to the client.
In step A, the HTTP request sent by the client includes the following parameters:
response_type: Indicates the authorization type, and the value here is fixed as "token", which is required.
client_id: Indicates the ID of the client, required.
redirect_uri: Indicates the redirected URI, optional.
scope: Indicates the scope of authority, optional.
state: Indicates the current state of the client. Any value can be specified, and the authentication server will return this value intact.
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
In step C, the authentication server responds to the URI of the client, including the following parameters:
access_token: Indicates the access token, which is required.
token_type: Indicates the token type, the value is case-insensitive and required.
expires_in: Indicates the expiration time, in seconds. If this parameter is omitted, the expiration time must be set in other ways.
scope: Indicates the scope of authority, if it is consistent with the scope applied by the client, this item can be omitted.
state: If the client's request contains this parameter, the authentication server's response must also contain this parameter exactly.
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600In the above example, the authentication server uses the Location column of the HTTP header information to specify the URL to which the browser is redirected. Note that the token is included in the Hash section of this URL.
According to step D above, the browser will visit the URL specified by Location in the next step, but the Hash part will not be sent. In the next step E, the code sent by the resource server of the service provider will extract the token in the Hash.
password mode
In password mode (Resource Owner Password Credentials Grant), the user provides his user name and password to the client. The client uses this information to request authorization from the "service provider".
In this mode, the user must give his password to the client, but the client must not store the password. This is usually used when the user has a high degree of trust in the client, such as the client being part of the operating system, or produced by a well-known company. The authentication server can only consider using this mode if other authorization modes cannot be implemented.
Steps:
(A) User provides username and password to client.
(B) The client sends the username and password to the authentication server, and requests a token from the latter.
(C) After the authentication server confirms that it is correct, it provides the access token to the client.
In step B, the HTTP request sent by the client includes the following parameters:
grant_type: Indicates the authorization type, and the value here is fixed as "password", which is required.
username: Indicates the username, which is required.
password: Indicates the user's password, which is required.
scope: Indicates the scope of authority, optional.
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
In step C, the authentication server sends the access token to the client
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}client mode
Client mode (Client Credentials Grant) means that the client authenticates to the "service provider" in its own name, not in the name of the user. Strictly speaking, the client mode is not part of the OAuth framework to solve the problem. In this mode, the user directly registers with the client, and the client requests the "service provider" to provide services in its own name, and there is actually no authorization problem.
Steps:
(A) The client authenticates to the authentication server and asks for an access token.
(B) After the authentication server confirms that it is correct, it provides the access token to the client.
In step A, the HTTP request sent by the client includes the following parameters:
granttype: Indicates the authorization type, and the value here is fixed as "clientcredentials", which is required.
scope: Indicates the scope of authority, optional.
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentialsThe authentication server must somehow authenticate the client.
In step B, the authentication server sends an access token to the client.
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
Reference documents: