OAuth 2.0 and related security issues (Part 1)

Tram Ho

In today’s technology age, logging in with accounts of other platforms is not unfamiliar to each of us. This is possible thanks to a few different mechanisms, one of which is OAuth 2.0. However, the application of OAuth 2.0 is also colorful, if there is a mistake, there can be holes for the bad guys to take advantage of. In this article we will learn a little bit about the vulnerabilities that can occur when using OAuth 2.0.

I. OAuth 2.0 Framework

1. OAuth 2.0 framework concept

First, I would like to quote the abstract of OAuth 2.0 Framework under the Internet Engineering Task Force (IETF) :

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

Accordingly, OAuth 2.0 is a mechanism that allows 3rd party services to have access to certain resources of the resource owner. OAuth 2.0 was originally designed to authenticate users’ access to certain resources. However, for its convenience, websites have come to realize that it is possible to use this framework to identify service users through information authenticated by the OAuth service provider.

Note : Usually the concept of OAuth mentioned will be about OAuth 2.0. However, there are still a few using lower mechanisms such as OAuth 1a. OAuth 2.0 was written completely new instead of going up from version 1, so the two versions, although the same OAuth, are completely different. If we only mention OAuth without saying anything more, we can default to OAuth 2.0.

2. OAuth Roles

As defined by IETF, in OAuth there are all 4 roles:

  • Resource owner: The user that owns the resource, usually understood as the end-user.
  • Resource server: is the place where resources are stored. Accessed and responded to through authentication mechanisms such as the access token.
  • Client: A service that requests access to the resource representing the resource owner and its authentication.
  • Authorization server: A service that provides access token to a client after successfully verifying a user and obtaining authentication of access to resources.

Actually, authorization can be on the same server as resource server or not. An authorization server can provide access token to multiple resource servers.

3. OAuth Grant Types

The OAuth grant type describes the exact sequence of steps in the OAuth process. Client also uses this sequence which determines the process of communicating with the authorization server so OAuth grant type is also known as OAuth Flows.

OAuth implementations are multicolored, so OAuth grant types are also incredibly diverse. There can be several of the most common ones such as:

  • Authorization Code grant type
  • Client Credentials grant type
  • Device Code grant type
  • Refresh Token grant type
  • Implicit grant type

In this article, I will talk mainly about Authorization code grant types and implicit grant types because the popularity of these two types is quite high.

a. Authorization code grant type

In this grant type, the client exchanges an authorization code to obtain the access token. This process can be described in the model below:

Explain each step of the process:

1. The client sends a request to the authentication server:

Which includes quite characteristic parameters such as:

  • clientid : A unique identifier of the client, generated when the client registers with an authorization service
  • redirecturi : is the uri that the browser uses to redirect to after receiving the authorization code. Often called the callback URI
  • responsetype : The response type that the client wants. Here is the code .
  • scope : the groups of data and resources that the client wants to access. Depending on each OAuth service that may vary.
  • state (optional): Is a unique and unpredictable value. Will be sent back in other responses and requests as callback request like a csrf token.

For example login with facebook (facebook uses openid, but the mechanism is not too different) request will look like this:

2. User login and permission permissions

After receiving the above initialization request, the browser will redirect the user to a login page to the OAuth provider system:

After successfully verifying the user, the authorization server will ask the user whether to provide specific permissions for the client application:

If the user agrees then the process will continue to the next step

3. Authorization server sends authorization code to client

After obtaining the consent of the user allowing access to resources, the authorization server will send back the client an authorization code.

4. Request access token

Once the authorization code has been obtained, the client will make a request to get the access token from the authorization server. This request will be created in a private channel that does not go through the browser. Client_secret will also be passed through this channel.

5. Client receives access token

When an authorization server receives a client’s request, it will respond to an access token corresponding to the authorization code sent

6. Execute API call

Once you have the access token, the client can now request the resources needed to get the resources.

7. Get required data

At this time, the resource server relies on the client’s access token and returns the corresponding data.

Advantages

Based on the model of the authorization code grant type, all important data (eg access token) does not go through the browser but through a separate channel between the client and the authorization server. This helps increase security during OAuth authentication. In addition, the client secret also uses this channel to transmit and send, so it is possible to ensure the security of this secret.

Defect

The only downside here is that the implementation is a bit more complicated than some of the others.

b. Implicit grant type

The implicit grant type is much simpler than the authorization code grant type. The reason is that it bypasses request authorization code which directly requests access token from authorization server side. The model of implicit grant types can be understood simply as follows:

Advantages

Simple, easy to deploy

Defect

All requests are sent through the browser instead of a separate channel between the client and the authorization server. This leads to the user data and access token can be hacked and stolen. In addition, protecting the client secret is not easy.

II. Security issues to consider when using OAuth 2.0

For a framework as powerful and flexible as OAuth 2.0, there are a lot of factors to consider in security. The factors I mentioned below are those indicated in RFC 6749 about OAuth 2.0 .

1. Verify users

  • User credentials MUST ALWAYS be confidential
  • Encourage the use of multi-factor authentication
  • DO NOT store passwords or other identifiers in native or user-agent-based applications for authentication purposes
  • Minimize the disclosure of any identifying information of the user (code, refresh token …)

2. Fake the user

  • The Authorization server must authenticate users whenever possible.
  • The authorization server should tell the user about the client application, scope and authorization time with the client.
  • The authorization server should not automatically handle repeated authorization requests.

3. Access tokens

  • Access tokens must be and always be kept confidential, stored and transmitted
  • Access token is only allowed to be accessed by an authorization server, resource server with valid access token and user possessing access token.
  • The access token must be transferred over the TLS protocol.
  • Access tokens must not be newly created, modified, or valued
  • Access tokens should be authorized to a minimum

4. Refresh tokens

  • Refresh tokens must be and always be confidential in storage and transmission
  • Refresh tokens are only accessible by an authorization server and the user possessing the access token.
  • Refresh tokens must be transmitted over the TLS protocol.
  • The authorization server must ensure that the token refresh corresponds to the user’s identity when the user is authenticated
  • If the user cannot authenticate, the authorization server must have other mechanisms to ensure token refresh is not taken advantage of
  • Refresh tokens must not be newly created, modified or valued

5. Authorization codes

  • The transmission of authorization code must be on a secure channel
  • The client must ensure that the redirect uri is authenticated over TLS
  • If the client uses authorization code as its method of authenticating resources, it must ensure that all transport is on the TLS protocol.
  • Authorization code must be short and disposable
  • If it is possible to authenticate the user, the client must authenticate the user and the authorization code corresponds to each other.

6. URI redirect handling in Authorization codes

  • Redirect URI is a sensitive point that hackers are very easy to exploit to attack OAuth mechanism
  • The authorization server must request the public client
  • The authorization server should ask the client to register for the redirect URI
  • The redirect URI must be checked, as opposed to the redirect URI client registered

7. The password of the resource owner

  • Minimize the use of resource owner password credentials grant type
  • Use other grant types if possible

8. The security of the request

  • Access tokens, refresh tokens, resource owner passwords, and client credentials may not be transmitted in cleartext
  • Authorization code should not be passed in cleartext
  • Parameters that may not pass or store securely such as state or scope should not contain sensitive client or resource owner information in cleartext.

9. Endpoint authentication

  • All requests between endpoints must be transmitted over the TLS protocol
  • The client must authenticate the TLS certificate of the authorization server

10. Attack “guess” credentials

  • Authorization server must ensure hacker cannot guess the value of access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials.
  • The probability that an attacker can guess the access token must be smaller 2 128 2 ^ {- 128} 2 1 2 8 and recommended to be smaller 2 160 2 ^ {-160} 2 1 6 0
  • The authorization server must have additional mechanisms in place to ensure end-user authentication.

11. Phishing attacks

  • Service providers should have mechanisms in place to make users more aware of phishing attacks
  • There should be multi-factor authentication mechanisms in place
  • To prevent phishing attacks, the authorization server must use the TLS protocol for all endpoints that interact with the end-user.

12. Cross-site request forgery (CSRF)

  • The authorization server must have mechanisms in place to protect against CSRF attacks for redirect_uri
  • Should use the state parameter as a csrf token for requests
  • The value of the csrf token must be guaranteed to be unpredictable
  • User-agent’s authentication state can only be accessed by client and user-agent (protected by Same-Origin Policy).

13. Click-jacking

  • Native apps should use an external browser instead of an embedded browser to perform authentication
  • For newer browsers, use the x-frame-options header to prevent the use of iframes
  • For lower versions of browsers, JavaScript frame-busting technique can be used (but not guaranteed with all browsers).

14. Code injection and Input validation

  • The authorization server must have mechanisms for checking, processing, and validating client-side submitted values, especially with the state and redirect_uri parameters.

15. Open redirect

  • The authorization server must have mechanisms for checking, processing, and validating client-side submitted values, especially with the state and redirect_uri parameters.

16. Misuse of access token in implicit flow

  • Access tokens of users can be stolen in many ways such as phishing, CSRF attack …
  • In implicit flow, authorization is very difficult to determine who is actually using the access token
  • An attacker with an access token stolen from a user can obtain user information from the resource server side

==> Since the implicit flow mechanism is very insecure, it is best not to use grant of this type

P / s: In this section, I talk about OAuth 2.0 and the security related factors of this framework. Part 2 I will demonstrate some types of attacks that can be performed to attack this authentication mechanism based on some of the vulnerabilities mentioned above.

References

Share the news now

Source : Viblo