[oauth2] II. Known changes in oauth2.1

Preface

OAuth2.0 Now it's more and more popular , Especially when microservices are popular . however OAuth2.0 Too old , The original OAuth2.0 To regulate in 2012 year 10 Month after month RFC 6749 The document is published in blueprint , To replace the 2010 year 4 Released on OAuth1.0, In the release OAuth2.0 When ,Vue、React Not yet , Even cross domain resource sharing CORS It's not official yet W3C standard .OAuth2.0 In the face of the rapid development of mobile Internet, it has become old , Can't keep up with the times . Fortunately OAuth2.0 Very open , Developers can do many custom operations , It puts a lot of “ Design authority ” Delegated to developers , After years of practice by developers ,OAuth2.0 The existing problems and defects have been repaired a lot , Even some process extensions let OAuth2.0 More robust .

OAuth The community assesses the situation , Drafted new new OAuth standard , It's called OAuth2.1, It's still in the draft stage . It will be eliminated in the new specification OAuth2.0 Some unsafe processes , Add OAuth2.0 Deficiency .

new OAuth2.1 What has changed ？

I think a lot of OAuth2 Developers want to know what's new OAuth2.1 What changes have taken place , Here I list some , Of course, limited by ability, it may not be complete .

Authorization code +PKCE

We all know OAuth2.0 The authorization code mode of is the most secure authorization mode . But in Africa TLS When link occurs , Some authorization processes in this mode may be intercepted, resulting in “ Man-in-the-middle attack ”. To prevent messages from being modified , An... Is added to the authorization code PKCE technological process RFC7636 be used for JavaScript A single page application , Later, it also introduced the mobile terminal PKCE standard RFC8252.

Implicit authorization is removed

In a single page application , Implicit authorization response_type=token Will attach the token to URL in , The front-end application will put the token in this storage 、 Session storage 、Cookie in , Either way, there is a risk of token leakage . The technology to eliminate this risk is expensive , Therefore, I do not recommend learning and using this method .

Password mode is removed

At least, password mode is widely used in China , A large number of developers ask for relevant details every day . Although this mode is easy to use , But it breaks the pattern of delegation , To reduce the OAuth2 The security of .

Its process is very similar to “ Phishing attacks ”, Imagine an application that randomly asks you to enter the password of another platform in the login page of one platform , If both platforms are trusted , There is nothing wrong with doing so , But for safety , This expands the area of leakage , This is an anti password mode , The user password may be exposed intentionally or unintentionally . And users cannot control the authorization process , Although users have limited scope, But client programs still provide programming opportunities to break the user's scope. If in public OAuth2 Use password mode on the client , Your token endpoint may also be sniffed , And then be brutally exhausted .

When password mode was born , Single page applications haven't sprung up yet , It is a transitional solution to solve the remaining problems .

Yes Refresh Token Limit

**Refresh Token（ Refresh token ）** Allow clients to retrieve new access tokens without re authentication . When the time of accessing resources exceeds the effective time of the access token , This mechanism is very helpful when the frequency of access is very low .Refresh Token Usually longer than the access token , Therefore, its safety should be paid more attention .

If they are acquired by an attacker , An attacker can create an access token at will , Security barriers will be in vain . OAuth 2.1 The draft specification is Refresh Token There are two options ： It can be used once , It can also be encrypted to ensure that it is not exposed in transmission .

How should we choose ？

Although at present OAuth2.1 It is still in the drafting stage , However, the above changes have been basically determined , The purpose is to make the authorization model more scientific and secure . For us ordinary developers , Stealth mode and password mode can be abandoned ,Spring Security Relevant functions and subsequent maintenance have been discarded . For single page applications, try to use Authorization Code+PKCE Pattern ; It is also targeted for mobile terminals PKCE programme ; And for IoT have access to Device Code Pattern .