OAuth2.0 authorization process under the front-end and back-end separation architecture

Front-end and back-end separation case code: spring-security-oauth2.0-sample

For the introduction of the OAuth2.0 specification, please refer to OAuth 2.0 Simplified
For the introduction of the OAuth2.1 draft, please refer to OAuth 2.1

1. The user clicks on the front end to start the third-party login
2. The front-end calls the back-end interface to start third-party login
3. After assembling client_id, redirect_uri, response_type, state and other parameters, the backend constructs a connection redirected to the third-party authorization server and returns it to the frontend. Links such as:http://wechat.com/oauth2/code?response_type=code&client_id=clientid&state=state&redirect_uri=http://我的应用前端地址
4. The redirect link goes back to the browser, and the browser is ready to start redirecting
5. Redirect to third-party application
6. The third-party application returns whether to authorize the page to the browser
7. The user clicks to agree to the authorization, and the browser returns the consent to the authorization server
8. The authorization server returns parameters such as code and state according to the previous redirect_uri
9. The front end submits the code and state parameters to the current application backend
10. The backend takes the code, state returned by the frontend and the client_id and client_secret parameters saved by the backend to authorize the server in exchange for accessToken and refreshToken. (client_secret can be transmitted through url (deprecated since OAuth2.1), header, body, commonly used basic method)
11. The authorization server verifies the parameters successfully, and returns accessToken and refreshToken to the backend
12. The backend takes the accessToken to the resource server in exchange for restricted resources
13. The resource server verifies the accessToken, and returns the restricted resource after success, and the backend can handle it according to the restricted resource
14. The backend can also return resources to the frontend for display...

Note : the front-end obtains the code first, that is, the front-end address is the address of redirect_url, wechat sends the code directly to the front-end, and then the front-end returns the code to the back-end (why not directly return to the back-end? Because the back-end will not and should not directly expose the interface For requests other than this application); even in the implicit mode, the front-end directly obtains the access_token without the participation of the back-end, which needs to ensure that the application is in a trusted environment. (The implicit and password modes were canceled in the OAuth2.1 draft).

The state parameter is used to prevent CSRF attacks. For this issue, please refer to What is the purpose of the 'state' parameter in OAuth authorization request .

In addition, the PKCE mechanism that is optional for OAuth2.0 and mandatory for OAuth2.1 can be used not only to prevent CSRF, but also to prevent authorization code injection attacks . For this issue, please refer to RFC 7636: Proof Key for Code Exchange , so you can use PKCE The state parameter is no longer needed.