OAuth 2.0 is an authentication and authorization industry standard that provides a simple and secure authentication and authorization method for a variety of applications (Web, desktop, mobile, device, etc.). oauth.net/2/
Security issues cannot be separated from trust:
For example, we all know that the pin number for your bank card can be entered at a cash machine. That’s because we trust cash machines.
For example, when you go to a convenience store and pay with your phone, you are prompted to enter your password. Because payment services trust you, not your phone.
Let’s look at OAuth 2.0 in terms of roles and authorization processes.
role
-
Resource Owner
A Resource Owner is the Owner of a Resource, usually an end user or sometimes a machine. So if you put money in a bank, the money is a Resource, and you’re the Resource Owner.
-
Resource Server
Resource Server is the custodian of resources, which is required to ensure the security of resources. Your bank is Resource Server.
-
Client
A Client is an application that needs to use resources, like your payment software.
-
Authorization Server
Authorization Server refers to the entity responsible for authenticating Resource Owner identity and Authorization. For example, your bank is the Authorization Server.
OAuth 2.0 defines the role separation between Resource Owner and Client, helping to clearly define the trust relationship.
The trust relationship between roles depends on the authorization process used.
Authorization process
-
Resource Owner Password Credentials GrantWe call this authorization process password authorization.
⚠️ In this process, the password is directly delivered to the Client and may be leaked. Therefore, you need to adopt secure transmission mode, do not transmit passwords in plain text, and desensitize logs when printing logs.
Password authorization is only used when other authorization is not available (such as when redirection is not supported).
-
Client Credentials GrantTo distinguish it from passwords, we call this a confidential authorization process. The Client Credentials are provided by the service provider when services are purchased from the service provider. Generally, it is the Client Id and Client Secret.
Client Credentials are confidential information that needs to be stored securely, so this process is commonly used on servers. In this case, the server is both Resource Owner and Client.
⚠️ its security issues are similar to password authentication. Because the server runs in a controlled environment, it is more secure than password authorization. However, you need to pay attention to it. For example, do not write confidential information in the configuration file in plain text. In the event of a leak, it should be replaced immediately. In addition, tools are available to help check for leaks, such as:
-
gittyleaks
-
Github Secret Scanning
-
Authorization Code GrantWe call this the authorization code authorization process. This process does not hand the password directly to the Client, so it avoids exposing the password to a third-party Client.
⚠️ Since code is passed through the URL, it can be leaked in the referrer header or otherwise. RFC 6819.
OAuth Draft Safety Practice 16 provides some countermeasures:
-
The Client suppresses the Referrer header with “referre-policy: no-referrer”
-
The Authorization Server authenticates the Client by PKCE and issues Access tokens only after the authentication succeeds
-
The Authorization Server limits the Authorization code to be exchanged only once, and revokes the issued Access Token upon repeated exchange
-
Use the return autosubmit form
-
Implicit GrantSince the Client is not authenticated during authorization, we call it implicit authorization. Implicit Authorization is intended to reduce the number of interactions between the Client and Authorization Server, but it has been considered to be prohibited due to its security problems without good countermeasures. Authorization code should be used.
⚠️ Implicit authorization causes Access Token leakage, and sender-constrained Access Tokens cannot be restricted because the Authentication Server does not authenticate the Client. Therefore, implicit authorization is prohibited.
In addition, in order to support devices with limited interaction, a Device Authorization Grant was added later, which will not be introduced in this article.
conclusion
To sum up, the four authorization processes of OAuth 2.0 take the following steps in relation to trust:
Trust relationship
Password authorization
Confidential work authorization
Authorization code
Implicit authorization
RO trust C
The user
The administrator
The user
The user
Trust AS C
https
https
https
https
AS trust C
Client Credentials
Client Credentials
Client Credentials+PKCE+ Checks the redirection address
N/A
C trust RS
https
https
https+state
https+state
RS trust C
Access Token
Access Token
Access Token
N/A
-
RO = Resource Owner
-
C = Client
-
AS = Authorization Server
-
RS = Resource Server
Security is an ongoing race, and there is no silver bullet. In addition, people’s safety awareness is also very important, technology and machines can not solve all problems.
Attached is a joke:
