OAuth Security: Complete Guide

Introduction

OAuth is a widely used authorization protocol that allows third-party services to access user resources without exposing their credentials. However, with its widespread adoption comes a host of potential vulnerabilities. This post will walk through the common vulnerabilities that can arise in client applications and in OAuth service, and how to effectively test and secure these implementations.

Before getting into the vulnerabilities lets understand a few common terms.

SSO

• SSO is an authentication process that allows a user to log in to multiple applications/systems with just one set of login credentials, such as a username/password.
• SSO consists of 3 key components: IdentityProvider (system that authenticates user), ServiceProvider (application that user wants to access using SSO) and AuthenticationProtocol.
• Authentication Protocol is a set of rules that define how IDP and SP communicate with each other to establish trust and exchange authentication information. Common protocols include SAML, OAuth2 and OIDC.

OAuth

• OAuth is a protocol that allow apps to access resources hosted on other apps without sharing user-passwords.
• Ex: A third-party app requests access to Google Drive files. Here, OAuth 2.0 is used purely for authorization, without involving authentication.

OIDC

• OpenID Connect (OIDC) is an authentication layer built on OAuth 2.0 that allows clients to verify user identity and obtain profile information.
• This process involves both authentication (verifying your identity) and authorization (granting profile information).
• Ex: Signing in to valorant(awful game) using Google. It uses OIDC to authenticate and Oauth to grant profile information (name, picture)

OAuth Grant Types

1. Authorization Code

• An authcode is issued by the AuthServer after the user approves, which is then used by the client to get the AccessToken.
• It is designed for confidential clients (such as server-side applications) that can securely store the Client_Secret .
• grant_type=authorization_code

2. Implicit (Deprecated)

• It is similar to AuthorizationCode Grant, except that AuthServer directly returns the access_code instead of auth_code . So, there is no client_secret involved.
• It was used by clients/apps which cannot maintain the confidentiality of the client_secret. Ex: Browser-based apps and Mobile apps.
• It is now deprecated as it was insecure. PKCE can be used instead.
• Here, any application could pretend to be the client (by knowing the client_id) increasing unauthorized access.

3. Authorization Code with Proof Key for Code Exchange (PKCE)

• PKCE is enhancement to AuthorizationCode Grant flow , adding security without the need for a client_secret, especially useful for public clients.
• Here, client needs to prove to the AuthServer that the auth_code is authentic by providing code_verifier , which is compared to code_challenge provided during the first step.
• This ensures that only the client that initiated the authorization request, can exchange the auth_code for an access_token .

4. Client Credentials

• Here, The client is authenticated by using its own client_id and client_secret to get an access_token.
• Used for non-interactive applications. Ex: automated processes, service-to-service communication, etc.
• grant_type=client_credential

5. Resource Owner Password Credentials

• Here, the client first requests the users to provide his credentials. It then uses this credential directly to get the access_token.
• It is used only where the client is highly trusted like first-party clients.
• grant_type=password

Identifying OAuth Authentication

There are specific parameters to look for during this phase:

• client_id: This parameter identifies the client application that is requesting access.
• redirect_uri: This is the URL where the authorization server will redirect the user after they approve or deny access.
• response_type: This parameter indicates what kind of response the client expects, such as an authorization code or a token.
• client_secret: This is used by client to authenticate its identity to Auth Server.

In addition to these parameters, it’s important to check the following endpoints on the authorization server. These endpoints often provide a JSON configuration file that details additional features the server supports:

• /.well-known/oauth-authorization-server
• /.well-known/openid-configuration

Examining these endpoints can reveal valuable information about the server’s configuration and the OAuth flow it supports.

Vulnerabilities in Client Applications

Once OAuth has been identified, the next step is to look for common vulnerabilities in the client application.

1. Client Secret Exposure

One of the first issue to check for is the exposure of the client secret. This secret should be treated with the same level of care as a password.

Get Pradeep Kumar’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Exploit: If the client secret is compromised, an attacker can pose as the legitimate client application. This allows them to request access tokens from the OAuth server, impersonating the client and potentially gaining unauthorized access to protected resources.

Recommendation: Ensure that client secrets are stored securely on the server side and are never exposed in client-side code or logs.

2. Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery is a major concern in OAuth implementations, especially if the state parameter is not used or properly validated. The state parameter helps prevent CSRF by ensuring that the response corresponds to a request initiated by the user.

Exploit:

1. Start by going through the OAuth authorization process as a user would.
2. After clicking authorize, intercept the request with the authorization code (e.g., https://x.com/callback?redirect=xyz&scope=xyz&code=AUTHCODE) and drop it.
3. This URL can then be sent to a logged-in victim user. If CSRF validation is missing or improperly handled, the attacker’s account could be linked to the victim’s account.

Recommendation: Always implement and validate the state parameter for every authorization request to prevent CSRF attacks.

3. Open Redirects

Open redirects are another vulnerability often encountered. If the redirect_uri parameter is not properly validated, an attacker can modify it to redirect the user to a malicious site, potentially stealing the authorization code.

Exploit:

1. Modify the redirect_uri in the OAuth flow to the attacker controlled URI.
2. Sending the malicious URL to the victim. https://sickuritywizard.com/auth?client_id=x&otherparams=xyz&redirect_uri=https://attacker.com
3. Once the victim completes the process, the victim’s authorization code can be captured and used to gain unauthorized access.

Recommendation: Validate the redirect_uri against a whitelist of approved URIs to prevent open redirects.

4. Access Token Exposure

It’s important to ensure that access tokens are not being exposed. Tokens can be vulnerable if they are passed through URL fragments or query parameters because URLs can be easily logged or cached in browser history, server logs or even third party analytics tools. This makes it vulnerable to unauthorized access.

Recommendation: Always pass tokens securely, preferably in HTTP headers or request body, to minimize the risk of exposure.

Vulnerabilities in the OAuth Service

Beyond the client application, it’s also important to focus on potential vulnerabilities within the OAuth service itself.

5. Improper Token Expiration

A key aspect of OAuth security is ensuring that access tokens have a proper expiration. Tokens that don’t expire or have excessively long lifetimes increase the risk of unauthorized access if they’re compromised.

Recommendation: Ensure that access tokens have short lifespans and implement mechanisms to revoke tokens if necessary.

6. ID Token Manipulation (OIDC)

When dealing with OpenID Connect (OIDC), which builds on OAuth, always check for ID token manipulation. If ID tokens are not properly validated, an attacker might manipulate them to impersonate another user.

Recommendation: Always validate the signature of ID tokens and ensure they are issued by a trusted source.

7. Scope Manipulation

Another common issue to look out for is scope manipulation. If an attacker can initiate the OAuth flow with additional, unauthorized scopes, they might gain more access than what the user intended to grant.

Recommendation: Validate and limit the scopes requested by the client to ensure they align with what the user has explicitly approved.

Thats all Folks, hit the clap button if you enjoyed the read.

Twitter -> https://twitter.com/sickuritywizard

Happy Hacking!