Oauth 2.0 authentication

 

What is Oauth 2.0

OAuth 2.0 stands for Open Authorization. OAuth is a delegation protocol that allows applications to access resources hosted by other web applications on behalf of a user. OAuth 2.0 is specifically an authorization protocol, not an authentication protocol. Its primary function is to grant access to a set of resources. OAuth 2.0 operates using Access Tokens. An Access Token is a data element that signifies authorization to access resources on behalf of the end-user. OAuth 2.0 does not specify a particular format for Access Tokens.

Visit here to discover more.

Problems with Oauth 1.0

• Basic signature workflow.
• Complex implementation of digital signatures at client-side.
• All transaction will be invalidate if a single message signed improperly.

Protect Your Business with Cutting-Edge Cybersecurity Services – Safeguard Your Data 24/7!

What Oauth 2.0 is not

• Is not an authentication protocol.
• It also does not define a method for user-to-user delegation.
• Doesn’t define authorization processing mechanisms.
• Doesn’t define a token format.
• Defines no Cryptographic methods.
• Is also not a single protocol.   

Component of Oauth 2.0

Terms	Description
Client	The application that seeks access to resources. Usually the third-party.
Resource Owner	The user who owns the resources. It can also be a machine
Resource	Could be images, data exposed via APIs, and so on.
Resource Server	Server that hosts protected resources. Typically, an API server that manages resources will grant access if a valid token is provided.
Authorization Server	Server responsible for authorizing the client and issuing access tokens.
Access Token	A token issued as a result of successful authorization.An access token is granted for specific permissions (scopes) and has a predetermined expiration time.
Refresh Token	A specialized token used to renew the access token.
User-Agent	The browser or mobile application through which the resource owner communicates with our authorization server.

How Oauth 2.0 WORKS

 

The Client initiates an authorization request by contacting the Authorization server, providing the client ID and secret for identification. Additionally, the Client supplies the scopes and a redirect URI (endpoint URI) where the Access Token will be sent.

The Authorization server then authenticates the Client and verifies that the requested scopes are permissible.

The Resource owner engages with the Authorization server to grant access.

Upon successful authorization, the Authorization server redirects back to the Client, returning either an Authorization Code or an Access Token, depending on the grant type, as detailed in the following section. A Refresh Token might also be issued.

Using the Access Token, the Client can then request access to the resource from the Resource server.

OAuth 2.0 Authentication Vulnerabilities in Web App Penetration Testing.

Flow in Oauth 2.0

• Authorization Code Grant
• Client Credentials Grant
• Resource Owner Password Credentials Grant
• Implicit Grant

Authorization Code Grant Flow

In authorization code grant flow a temporary authorization code is created that the client will exchange for an access token the code obtained for authorization server.

Authorization Request Parameters

These parameters are used to make the authorization requests.

response_type = code	This indicates that the response should be an authorization code.
client_id	This is the public identifier for your app, provided when you first registered your app with the service.
redirect_uri	While this parameter may be optional depending on the API, it is strongly recommended. It specifies the URL to which the user will be redirected after the authorization process is complete. This must match the redirect URL previously registered with the service.
scope	One or more scope values (separated by spaces) should be included to request specific levels of access. The specific values will vary based on the service.
state	The state parameter serves a dual purpose. When the user is redirected back to your app, the state value will be included in the redirect. This allows your app to persist data between the initial authorization request and the return from the authorization server. It can also be used to determine the subsequent action in the app, such as deciding which page to redirect to after authorization.

 

When application requesting for an authorization code and exchange it for an access token which give access to users account details.

Client Credentials Grant flow

The Client Credentials Grant flow is used for machine-to-machine communication. Since the client is inherently confidential, applications may need to act on their own behalf rather than on behalf of a user.

 

The Request URL includes your application’s URL followed by the /oauth2-token slug. Ensure that the content-type is specified in the headers.

Content-Type: application/json

Send a POST request to the authorization server with the necessary body parameters.

• grant_type with the value client_credentials
• client_id with the client’s ID
• client_secret with the client’s secret ID

 

The authorization server will respond with a JSON object containing these properties:

• token_type set to “Bearer”
• expires_in set to 3600 seconds, indicating that the token is valid for one hour and can be used multiple times within that period. You can configure the expiration time in the config/config.yml file of your application.
• access_token which is a JSON Web Token (JWT) signed using the authorization server’s private key.

Resource Owner Password Credentials Grant flow

Resource Owner Password Credentials Grant flow is used by highly trusted applications where requests that users provide are sent to the back-end and can be stored for future use before being exchanged for an access token.

 

1. when user clicks Login within the application and enters their credentials. application forwards the user’s credentials to your Auth0 Authorization Server.
2. Auth0 Authorization Server validates the credentials.
3. Authorization Server responds with an Access Token (and optionally, a Refresh Token).
4. Application can use the Access Token to call an API to access information about the user.
5. The API responds with requested data.

Implicit Grant Flow

It can be an alternative to authorization code grant for public clients .In Implicit grant flow the public client does not contain the client_secret and there is no back channel communication is involved.

 

the access token is obtained immediately and passed in URL fragments. the access token will extracted in this manner and subsequent calls are made to fetch the resources and this flow is susceptible to access token leakage and replay attacks. It is not to recommend to use Implicit grant flow.

Pen-Testing Oauth 2.0

Insufficient Redirect URI Validation :- Some authorization servers allow clients to register redirect_uri patterns instead of full redirect_uri. Authorization servers then match the redirect_uri parameter value to the authorization endpoint against a pattern registered at runtime. This approach allows clients to encode transaction status into additional redirect_uri parameters or to register a single pattern for multiple redirect_uri. To implement this approach than matching the exact redirect_uri on sending the user agent directly to a URI under attacker control, or by exposing OAuth credentials to an attacker using an open redirection on the client in conjunction with the way user agents handle URL fragments.

Steps :- Attacker trick the user into opening a tampered URL that launches under the attacker’s control URL the vulnerable URL looks like this.

GET /authorize?response_type=code&client_id=A6CXXXX3&state=9ad67f13 &redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example.com
HTTP/1.1
Host: server.somesite.example.com

The authorization server validates the redirect URI and compares it to the registered redirect URL patterns for the client A6CXXXX3. The authorization request is processed and presented to the user.The code is issued and sent to the attacker’s domain.

Mitigation :-For preventing open redirection , clients should only redirect if the target URLs are whitelisted or id the origin and integrity of a request can be authenticated.

Cross Site Request Forgery :- By performing a CSRF attack , an attacker can achieve account takeover by linking his account to the victim’s account. The attacker forces authenticated users to submit a request to application.

Steps :- For this attack attacker required a dummy account. Attacker intercept the merge account request and generates CSRF POC and drop the request from burp-suite in order not to consume the authorization_code as it can be used only once . By adding null byte character in state parameter attacker host that CSRF POC on evil.com. Once victim visit evil.com his account will be compromised.

Mitigation :-For preventing CSRF attack. Client should implement state parameter however it is a optional header. CSRF tokens that are bound to the user agent and passed in the state parameter to the authorization server. It is impossible for an attacker to forge the request without knowing the state. Which is specific to user only.

Authorization Code Injection :- The attacker tries to inject a stolen code into attacker’s session with the client. The purpose is to associate the attacker’s session on the client with the victim resources.

Steps :-Attacker require authorization code for testing the authorization code injection. Attacker performs a oauth authorization process with the legitimate client on this device and injects the stolen authorization code in the response of the authorization server. Legitimate client sends the code to the authorization server’s token endpoint, along with the client’s client_id, client secret and actual redirect_uri. The authorization server issues access and other tokens to the client. The attacker has now associated his session with the legitimate client with the victim’s resources

Mitigation :- It is recommended to bind the state to the code, using token binding for the code. There are some other ways PKCE and Nonce. PKCE and Nonce also have limitations. The Attacker can modify the nonce or code_challenge values that are used in the victim’s authorization request. By modifying these values to be the same ones as those chosen by the client in his own session.

Credential Leakage via Browser History :- While a browser navigates to client.example/redirection_endpoint?code=abXXXAC as a result of a redirect from a provider’s authorization endpoint, the URL together with the authorization code may emerge as in the browser’s history. An attacker with access to the device can acquire the code and attempt to replay

Steps :-Attackers need victim device access. The attacker gets the authorization code and access token by visiting the browser history and try to replay it

Mitigation :- It is recommended to use form post response mode instead of redirect for the authorization response.

Access token Injection :- The attacker attempts to inject a stolen access token into a legitimate client access_token considered independent of any client. It ensures that an access_token saved at the authorization server with appropriate scopes and expiration time.

Steps :- The attacker starts offevolved an OAuth flow with the client using the implicit grant and modifies the authorization response by using replacing the access token issued by means of the authorization server.

Mitigation :- It is recommended to use the authorization code grant type instead of relying on response types issuing access tokens at the authorization endpoint.

Contact us: +91 9900 53 7711

Please write to us: info@bornsec.com

Visit us: https://bornsec.com/