OAuth 2.0
Last updated
Last updated
OAuth is a commonly used authorization framework that enables websites and web applications to request limited access to a user's account on another application. Crucially, OAuth allows the user to grant this access without exposing their login credentials to the requesting application. This means users can fine-tune which data they want to share rather than having to hand over full control of their account to a third party.
Client
The website or web application that wants to access the user's data. It must be registered on the OAuth server, and thus have an ID and a Secret.
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. It must be configured to support a particular "grant type" that are a different ways that the actual OAuth process can be implemented.
Client --> OAuth server
client_id
Unique identifier of the client application
redirect_uri
The URI to which the user's browser should be redirected when sending the authorization code to the client application.
response_type
The grant type ("code")
scope
Subset of user data that the client wants to access. It can be a custom scopes set by the OAuth provider or standardized scopes defined by the OpenID Connect specification
state
Unique, unguessable value that is tied to the current session on the client application. This parameter serves as a form of CSRF token for the client application by making sure that the request to its /callback endpoint is from the same person who initiated the OAuth flow.
Client <-- OAuth server
OAuth server redirect to redirect_uri but only if the registered_uri has been registered before (security reasons, but it is not always implemented).
Once the authorisation code has been received, and checked the state, communication takes place between the backend servers, and thus not observed by the user. The client application can use the authentication code to obtain an access token. This token is used to obtain the user's information via API calls to the OAuth server. When get the token, the client application must authenticate itself by including the secret key that it was assigned when registering with the OAuth service.
The implicit grant type is much simpler. Rather than first obtaining an authorization code and then exchanging it for an access token, the client application receives the access token immediately after the user gives their consent (it is far less secure).
Client --> OAuth server
The only major difference is that the response_type parameter must be set to "token".
Client <-- OAuth server
Once the client application has successfully extracted the access token from the URL fragment, it can use it to make API calls to the OAuth service's /userinfo endpoint. Unlike in the authorization code flow, this also happens via the browser.
OpenID Connect extends the OAuth protocol to provide a dedicated identity and authentication layer
On OAuth server
/.well-known/oauth-authorization-server
/.well-known/openid-configuration
Try adding the openid scope or changing the response type to id_token
If the application fails to use the state parameter, an attacker could potentially hijack a victim user's account on the client application by binding it to their own social media account.
Login with your account
Go to attach your account on your social (Client --> OAuth server)
Send the Client <-- OAuth server request on the victim
Now your local account is associated with the victim's social account, so if you logout and login with social you will be in the victim's account.
Note that if the site allows users to log in exclusively via OAuth, the state parameter is arguably less critical. However, not using a state parameter can still allow attackers to construct login CSRF attacks, whereby the user is tricked into logging in to the attacker's account.
By stealing a valid code or token, the attacker may be able to access the victim's data (could potentially log in as the victim user on any client application that is registered with this OAuth service). If the OAuth service does not properly validate the URI specified in the redirect_uri parameter, an attacker could exploit this vulnerability to perform a CSRF-like attack. This would trick the victim's browser into initiating an OAuth flow that sends the code or token to an attacker-controlled redirect URI.
If the OAuth service checks the redirect URI with a previously configured whitelist, it is possible to attempt to escape.
You should try removing or adding arbitrary paths, query parameters, and fragments to see what you can change without triggering an error.
Discrepancies between the parsing of the URI (URL validation bypass)
Duplicate redirect_uri parameters
Redirect URI beginning with localhost (ex. localhost.evil-user.net)
Use directory traversal tricks to supply any arbitrary path (ex. https://client-app.com/oauth/callback/../../example/path)
Try to experiment with different combinations of changes to several parameters (ex. different response_mode could allow you to submit URIs that would otherwise be blocked)
some providers will allow dynamic client registration without any authentication, which enables an attacker to register their own malicious client application.
SSRF in logo
