Understanding OAuth 2.0

Preface

OAuth 2.0 Is a standard protocol for authorization .OAuth 2.0 Focus on providing simplified authorization process for client developers , Include Web application 、 Desktop application 、 Smart phone applications and IOT living devices （ For example, TV ）. Its documentation and extensions are in here Have a show .

The above paragraph is OAuth 2.0 A description on the official website . Some of these keywords ： to grant authorization 、 standard 、 Simplification and various scenarios .

First, let's look at authorization , English is Authorization, An easily confused word is authentication , English is Authentication. For these two concepts , stay here There is a comparison . The author summarizes the content of the article ：

The purpose of authentication is to confirm that the user is the user , Authorization is to give users access to resources , Authentication methods currently include passwords 、 One time password 、 Authentication applications and biometric credentials ; Examples of authorization include permission to access specific files on the server 、 Use the administrative permission of the application ; Of course, in many cases, authorization is closely related to authentication , For example, a developer owns a sub account of Tencent cloud , Log in with a password （ authentication ） after , You can operate the master account （ to grant authorization ） Some of CVM（ allow ）, However, you cannot access the primary account COS resources （ Refuse ）.

therefore OAuth 2.0 Authorization, not authentication .

Four patterns

About OAuth 2.0 The four modes are generally mentioned ,

• Authorization Code
• Client Credentials
• Implicit Flow
• Password Grant

I will not introduce the above four modes here , Because there have been a lot of articles on the Internet about this , Here the author just makes some supplements to the content here .

Authorization Code Is the most recommended process , This mode should be used without special restrictions .

Client Credentials The back-end using , There is no compromise .

Implicit Flow because Some security issues It is not recommended to use , Be similar to such pure Web End applications can use this mode , But now there are new programme .

Password Grant Mode because the password trustee is out of control , It is not recommended to use , It can even be said that the use of .

PKCE

About mobile applications without background applications （ Also called native application or public application ） Need to use PKCE（Proof Key for Code Exchange） Pattern , Is based on Authorization Code The pattern is extended , Because native applications cannot guarantee client_secret The confidentiality of , Or not client_secret At all , So as long as the hijacking reaches Authorization Code Malicious applications can get Access Token,rfc7636 The described hijacking process is as follows ,

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| End Device (e.g., Smartphone)  |
|                                |
| +-------------+   +----------+ | (6) Access Token  +----------+
| |Legitimate   |   | Malicious|<--------------------|          |
| |OAuth 2.0 App|   | App      |-------------------->|          |
| +-------------+   +----------+ | (5) Authorization |          |
|        |    ^          ^       |        Grant      |          |
|        |     \         |       |                   |          |
|        |      \   (4)  |       |                   |          |
|    (1) |       \  Authz|       |                   |          |
|   Authz|        \ Code |       |                   |  Authz   |
| Request|         \     |       |                   |  Server  |
|        |          \    |       |                   |          |
|        |           \   |       |                   |          |
|        v            \  |       |                   |          |
| +----------------------------+ |                   |          |
| |                            | | (3) Authz Code    |          |
| |     Operating System/      |<--------------------|          |
| |         Browser            |-------------------->|          |
| |                            | | (2) Authz Request |          |
| +----------------------------+ |                   +----------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

The hijacking process is in the (4) Step , For detailed explanation, see rfc7636 perhaps here perhaps here . In a back-end scenario , We generally think that Authorization Code Mode is safe enough , But on the client side Authorization Code In the risk scenario of being hijacked ,PKCE Is a required option .

Why Authorization Code（ Authorization code ）

standard Authorization Code The mode flow is as follows ,

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

Need to explain , technological process A B They are all front-end processes , and C D Processes are all back-end processes , The front-end process can be considered as weak security and the back-end , And the convenience of front-end interaction is better than that of back-end , So take it through the front end Authorization Code More convenient , And take it through the back end Access Token More secure .

Why OpenID Connect

OpenID Connect The home page of here . First of all, clear OpenID Connect be based on OAuth 2.0, Is a simple authentication layer , Allow the client to verify the identity of the end user . here This paper describes the protocol standard for obtaining the identity information of end users , for example Authorization Code In mode ,Authorization Request in scope Must be carried in openid. stay Access Token Reply will return id_token Field , here Yes ID Token Explanation , At the same time, the standard specifies the remote verification interface tokeninfo, This additional information acquisition interface userinfo. therefore , In the absence of OpenID Connect If you need to authenticate the user's information , Identity providers need to provide non-standard interfaces through Access Token To get .

state And nonce

Here we discuss the functions of the two . In summary, it is state For authorization requests , This allows the client to verify that the response is from the original authorization server , That is, cross station check of authorization response ; and nonce Appear in the OpeID Connect In the description , If the client uses , Then it will appear in id_token in , So it can also be used to check id_token Whether it comes from the original authorization server , namely id_token Cross station inspection of ;

Summary

Combing OAuth 2.0 When , The author finds that there have been widely used or emerging standards before , Now it has become deprecated or even abandoned , And it was once considered a standard process specification , It has to be enhanced because of security problems . in addition OAuth 2.0 Although the solution is Authorization , But there are many application scenarios , And will keep pace with the times , Such as OAuth 2.1 It has been proposed that , Try to be on OAuth 2.0 Simplify . therefore , A standard will have more vitality only if it closely follows the application scenarios and technology development .