Client application - The website or web application that wants to access the user's data.
Resource owner - The user whose data the client application wants to access.
OAuth service provider - The website or application that controls the user's data and access to it. They support OAuth by providing an API for interacting with both an authorization server and a resource server.
Scope - The range of data for which access is requested.
The ways that OAuth can be implemented.
Authorization Code - the client application and OAuth service first use redirects to exchange a series of browser-based HTTP requests that initiate the flow. The user is asked whether they consent to the requested access. If they accept, the client application is granted an "authorization code". The client application then exchanges this code with the OAuth service to receive an "access token", which they can use to make API calls to fetch the relevant user data.
Implicit - the client application receives the access code immediately after the user gives their consent.
If you see an option to log in using your account from a different website, this is a strong indication that OAuth is being used.
Proxy your traffic through something like Burp or ZAP and check the corresponding HTTP messages when you attempt to login. Regardless of which OAuth grant type is being used, the first request of the flow will always be to /authorization with a number of query parameters used specifically for OAuth. Make sure you look out for the client_id, redirect_uri, and response_type parameters.GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com
Once you know the hostname of the auth server, you should test it with a GET request to these standard endpoints:
/.well-known/oauth-authorization-server
/.well-known/openid-configuration
If there is a response from the auth server, often times it will reply with a JSON file ripe with information that we can use, such as leads to a larger attack surface and config information.
OAuth Attacks
Improper implementation of the Implicit Grant type.
The client application will often submit a UserID and Access token to the server in a POST request, in order to be assigned a session cookie, essentially logging them in.
If the client application doesn't properly check that the access token matches the other data in the request, an attacker can manipulate the contents of the post request to impersonate any other user they choose.
Change the UserID value in the POST request to see if you can impersonate other users.
The optional state parameter of the OAuth request, is often users as a CSRF token for the client application.
If the stateparameter is not set, you can perform an attack similar to a traditional CSRF, where an attacker can initiate an OAuth flow themselves before tricking a user's browser into completing it.
Depending on the grant type, either a code or token is sent via the victim's browser to the /callback endpoint specified in the redirect_uri parameter of the authorization request. If the OAuth service fails to validate this URI properly, an attacker may be able to construct a CSRF-like attack, tricking the victim's browser into initiating an OAuth flow that will send the code or token to an attacker-controlled redirect_uri
When auditing an OAuth flow, you should try experimenting with the redirect_uri parameter to understand how it is being validated.
Generally, when a token is granted, it is only for the scope defined in the request. However it is possible to "upgrade" the scope of access by exploiting a flawed OAuth implimentation.
With the authorization code flow, it may be possible for an attacker to register their own client application with the OAuth service.
With the implicit grant flow, tokens are sent via the browser and an attacker can steal tokens associated with innocent client applications and use them directly. Once they have stolen an access token, they can send a normal browser-based request to the OAuth service's /userinfo endpoint, manually adding a new scope parameter in the process.
Unverified user registration
Some websites that provide an OAuth service allow users to register an account without verifying all of their details, including their email address in some cases. An attacker can exploit this by registering an account with the OAuth provider using the same details as a target user, such as a known email address.
OAuth token stealing: Changing redirect_uri to attacker(.)com(Use IDN Homograph or common bypasses).
Change Referral header to attacker(.)com while requesting OAuth.
Create an account with victim@gmail(.)com with normal functionality. Create account with victim@gmail(.)com using OAuth functionality. Now try to login using previous credentials.
OAuth Token Re-use.
Missing or broken state parameter.
Lack of origin check.
Open Redirection on another endpoint > Use it in redirect_uri
If there is an email parameter after signin then try to change the email parameter to victim's one.
Try to remove email from the scope and add victim's email manually.
Only company's email is allowed? > Try to replace hd=company(.)com to hd=gmail(.)com
Check if its leaking client_secret parameter.
Go to the browser history and check if the token is there.
OpenID Connect extends the OAuth protocol to provide a dedicated identity and authentication layer that sits on top of the basic OAuth implementation.
OpenID Connect slots neatly into the normal OAuth flows. From the client application's perspective, the key difference is that there is an additional, standardized set of scopes that are the same for all providers, and an extra response type: id_token.
Relying party - The application that is requesting authentication of a user. This is synonymous with the OAuth client application.
End user - The user who is being authenticated. This is synonymous with the OAuth resource owner.
OpenID provider - An OAuth service that is configured to support OpenID Connect.
The term "claims" refers to the key:value pairs that represent information about the user on the resource server.
Unlike basic OAuth, whose scopes are unique to each provider, all OpenID Connect services use an identical set of scopes. In order to use OpenID Connect, the client application must specify the scope openid in the authorization request.
They can then include one or more of the other standard scopes:profile, email, address, phone
The other main addition provided by OpenID Connect is the id_token response type. This returns a JSON web token (JWT) signed with a JSON web signature (JWS). The JWT payload contains a list of claims based on the scope that was initially requested. It also contains information about how and when the user was last authenticated by the OAuth service.
Unprotected dynamic client registration
If dynamic client registration is supported, the client application can register itself by sending a POST request to a dedicated /registration endpoint. The name of this endpoint is usually provided in the configuration file and documentation.
In the request body, the client application submits key information about itself in JSON format.
some providers will allow dynamic client registration without any authentication, which enables an attacker to register their own malicious client application.