Spring Security and OAuth2 Introduction

Personal OAuth2 all articles

• Spring Security and OAuth2 (introduction): Https://www.jianshu.com/p/68f22f9a00ee
• Spring Security and OAuth2 (authorization server): HTTPS://WWW.JIANSHU.COM/P/227F7E7503CB
• Spring Security and OAuth2 (Resource server): https://www.jianshu.com/p/6dd03375224d
• Spring Security and OAuth2 (client): https://www.jianshu.com/p/03e515c2b43f
• Spring Security and OAuth2 (related class reference): Https://www.jianshu.com/p/c2395772bc86
• Spring Security and OAuth2 (full case): https://www.jianshu.com/p/d80061e6d900

Summary : The advantage of using OAUTH2 certification is that you only need an account password, you can access the various sites, and the face to each site to register the cumbersome process, such as: Many sites can use the login, the site as a third-party service, as a service provider

OAuth2 role

• ResourceOwner: Resource owner (referred to as user)
• ResourceServer: The resource server holds the protected resource and access to these resources requires an access token (the Twitter resource server in the following example)
• Client: The client represents a third-party program that requests resource server resources (Quora in the example below) and it may also be a resource server
• authrizationServer: The authorization server is used to issue an access token to the client (the Twitter license server in the following example)

OAuth2 Work Flow Example

• Client Quora registers itself on the authorization server
• The user accesses the Quora home page, which displays various login options
• When the user clicks on the Twitter login, Quora opens a new window and redirects the user to the Twitter landing page.
• In this new window, the user uses his account password to log on to Twitter.
• If the user has not previously authorized the Quora application to use their data, Twitter requires the user to authorize Quora to access the user's information rights, and if the user has authorized Quora, this step is skipped
• After proper authentication, Twitter redirects the user and an authentication code to the Quora redirect URI
• Quora Send client ID, client token, and authentication code to Twitter
• After the Twitter validates these parameters, it sends the access token to the Quora
• After successfully obtaining the access token, the user is logged on to Quora and the user logs on to Quora and clicks on their profile page.
• Quora requests a user's resources from a Twitter resource server and sends an access token
• Twitter resource server authenticates access tokens with Twitter authorization server
• After successfully validating the access token, the Twitter resource server provides the required resources to the Quora
• Quora use these resources and eventually display the user's profile page

OAuth2 licensing Mode (from Nanyi OAuth2 blog) Authorization Code mode

• The Authorization Code mode is the most complete and the most rigorous licensing mode, it is characterized by the client's backend server, and "server-provided" authentication server to interact

9434708-a464c0c64ca6ee9a.png

• Its steps are as follows:
  • (A) User access to the client, which directs the former to the authentication server
  • (B) The user chooses whether to grant the client authorization
  • (C) Assuming that the user gives authorization, the authentication server directs the user to the "redirect URI" specified by the client, with an authorization code
  • (D) The client receives an authorization code with an earlier "redirect URI" requesting a token from the authentication server, which is done on the client's backend server and is not visible to the user
  • (E) authentication server verifies authorization code and redirect Uri, sends token and update token to client after confirmation is correct
• The parameters required in the above steps:
  • In step A, the client requests the URI for authentication, which contains the following parameters:
    • Repsone_type: Authorization type, required, here fixed value "code"
    • CLIENT_ID: ID of the client, required
    • Client_secret: Client's password, optional
    • Redirect_uri: redirect Uri, optional
    • Scope: Permission range for the application, optional
    • State: The current status of the client, you can specify any value, the authentication server will return the value intact

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: server.example.com

  • In the C step, the server responds to the client's URI, which contains the following parameters:
    • Code: The authorization code, must press, the code should be short, usually 10 minutes, the client can only use one time, otherwise it will be denied by the authorized server, the code and the client ID and redirect URI is one by one correspondence
    • State: If the client request contains song parameters, the authentication server's response must also contain this parameter exactly

    HTTP/1.1 302 FoundLocation: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

  • In step D, the client requests an HTTP request for a token from the authentication server, which contains the following parameters:
    • Grant_type: Indicates the authorization mode used, required, where the fixed value is "Authorization_code"
    • Code: Indicates the authorization obtained in the previous step, required
    • Redirect_uri: Redirect Uri, required, consistent with step A
    • CLIENT_ID: Indicates the client ID, required

    POST /token HTTP/1.1Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

  • In the
  • e step, the authentication server sends an HTTP reply that contains the following parameters:
    • access_token: Indicates token, required
    • Token_type: Represents the token type, which is case insensitive, required, can be of type bearer or Mac type
    • expires_in: Indicates the expiration time, in seconds, and if omitted, you must set a different expiration time
    • Refresh_token: Represents an update token for obtaining the next access token, optional
    • Scope: Represents a permission range

    http/1.1 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 can be seen from the above code, parameters are sent in JSON format (Content-type:application/json), only outside the HTTP header information explicitly specified must not be cached

Simplified mode

• Simplified mode request a token from the authentication server directly in the browser without a third-party application's server, skipping the "Authorization Code" step

Bg2014051205.png

• Its steps are as follows:
  • (A) The client directs the user to the authentication server
  • (B) The user decides whether to grant the client authorization
  • (C) Assuming that the user gives authorization, the authentication server directs the user to the "redirect URI" specified by the client and includes an access token in the hash portion of the URI
  • (D) The browser makes 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 that can get tokens in a hash value
  • (F) The browser executes the script obtained in the previous step and takes out the token
  • (G) The browser will send the token to the client
• The parameters required in the above steps:
  • a step, the client issues an HTTP request that contains the following parameters:
    • Response_type: Represents the authorization type, where the fixed value is "token", Required
    • client_id: Indicates the client ID, required
    • redirect_uri: Represents the redirect Uri, optional
    • scope: Represents a permission range, optional
    • state: Indicates the client's current status, can specify any value, and the authentication server returns this value unchanged

      get/authorize?response_type=token&client_id=s6bhdrkqt3&state=xyz& REDIRECT_URI=HTTPS%3A%2F%2FCLIENT%2EEXAMPLE%2ECOM%2FCB http/1.1host:server.example.com  

  • In the C step, the authentication server responds to the client's URI, which contains the following parameters:
    • Access_token: Represents an access token, required
    • Token_type: Represents the token type, which is case insensitive, required
    • Expires_in: Indicates the expiration time in seconds
    • Scope: Represents a permission range that can be ignored if the scope of the client request is consistent
    • State: If this parameter is included in the client request, the authentication server will return identical parameters

    HTTP/1.1 302 FoundLocation: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

• In the example above, the authentication server uses the location bar of the HTTP header information to specify the URL of the browser redirect, noting that the hash portion of the URL contains the token
• According to the D step, the next browser will access the URL specified by the location, but the hash portion will not be sent, the next e-step, the service provider's resource server sent over the code, extract the hash token

Password mode

• In password mode, the user provides his or her user name and password to the client, who uses the information to request authorization from the service provider.

• In this mode, the user must give the password to the client, but the client should not store the password, which is usually in the case of high-end client trust, such as the client is part of the operating system, by a well-known company, and the authentication server only if the other licensing mode can not be implemented in the case of the mode is considered

9434708-6165f69e2bfc8881.png

• Its steps are as follows:
  • (A) User name and password provided to the client
  • (B) The client authenticates the user name password to the server, requesting the token from the latter
  • (C) An access token is provided to the client after the authentication server has confirmed the error
• The parameters required in the above steps:
  • In step B, the client issues an HTTP request that contains the following parameters:
    • Grant_type: Authorization type, required, fixed value "password" here
    • Username: Indicates user name, required
    • Password: Indicates user password, required
    • Scope: Permission range, 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

  • C Step, the authentication server sends an access token to the client, here is an example:

    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 refers to the client in its own name, not the user name, to the "service provider" certification, strictly speaking, the client mode is not part of the OAuth framework to solve the problem, in this mode, the user directly to the client registration, the client in its own name request "service provider" to provide services

Bg2014051207.png

• Its steps are as follows:
  -(A): The client authenticates to the authentication server and requires an access token
  -(B): After the authentication server is confirmed, provide the access token to the client

• The parameters required in the above steps:

  • In step A, the client issues an HTTP request that contains the following parameters:

    • Granttype: Represents the authorization type, where the fixed value is "clientcredentials", required
    • Scope: Represents a permission range, optional

     POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=client_credentials

  • In step b, the authentication server sends an access token to the client, and here's an example

     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" }

Update tokens

• If the client access token has expired when the user accesses it, you need to request a new token using the update token
• The client issues an update token request that contains the following parameters:
  • Granttype: Represents the licensing mode, where the fixed value is "Refreshtoken", required
  • Refresh_token: Indicates a previously received update token, required
  • Scope: Indicates the scope of the request permission, must not exceed the scope of the last request, if omitted, it is the same as the last time

   POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

This article is reproduced from

Lin Yuan

Source: Pinterest

Links: Https://www.jianshu.com/p/68f22f9a00ee

Spring Security and OAuth2 Introduction