resource owner
is the user/entity granting access to their protected resource, such as their Twitter account Tweets. In this example, this would be you.resource server
is the server handling authenticated requests after the application has obtained an access token
on behalf of the resource owner
. In this example, this would be https://twitter.comclient application
is the application requesting authorization from the resource owner
. In this example, this would be https://yourtweetreader.com.authorization server
is the server issuing access tokens
to the client application
after successfully authenticating the resource owner
and obtaining authorization. In the above example, this would be https://twitter.comclient_id
is the identifier for the application. This is a public, non-secret unique identifier.client_secret
is a secret known only to the application and the authorization server. This is used to generate access_tokens
response_type
is a value to detail which type of token is being requested, such as code
scope
is the requested level of access the client application
is requesting from the resource owner
redirect_uri
is the URL the user is redirected to after the authorization is complete. This usually must match the redirect URL that you have previously registered with the servicestate
parameter can persist data between the user being directed to the authorization server and back again. It’s important that this is a unique value as it serves as a CSRF protection mechanism if it contains a unique or random value per requestgrant_type
parameter explains what the grant type is, and which token is going to be returnedcode
is the authorization code received from the authorization server
which will be in the query string parameter “code” in this request. This code is used in conjunction with the client_id
and client_secret
by the client application to fetch an access_token
access_token
is the token that the client application uses to make API requests on behalf of a resource owner
refresh_token
allows an application to obtain a new access_token
without prompting the userredirect_uri
with the code
and state
parameters:code
, and using their application’s client_id
and client_secret
, will make a request from the server to retrieve an access_token
on behalf of you, which will allow them to access the permissions you consented to:access_token
to access your Tweets.redirect_uri
is very important because sensitive data, such as the code
is appended to this URL after authorization. If the redirect_uri
can be redirected to an attacker controlled server, this means the attacker can potentially takeover a victim’s account by using the code
themselves, and gaining access to the victim’s data.redirect_uri
path as specified in the client application**, but some will accept anything in the same domain or subdirectory of the redirect_uri
.redirect_uri
. In a situation where a redirect_uri
is https://yourtweetreader.com/callback, these include:https://yourtweetreader.com/callback/../redirect?url=https://evil.com
redirect_uri
regexes: https://yourtweetreader.com.evil.com
https://yourtweetreader.com/callback/home/attackerimg.jpg
.well-known/openid-configuration
**sometimes contains parameters such as "registration_endpoint", "request_uri_parameter_supported", and "require_request_uri_registration". These can help you to find the registration endpoint and other server configuration values.state
parameter is completely omitted or used in the wrong way. If a state parameter is nonexistent, or a static value that never changes, the OAuth flow will very likely be vulnerable to CSRF. Sometimes, even if there is a state
parameter, the application might not do any validation of the parameter and an attack will work. The way to exploit this would be to go through the authorization process on your own account, and pause right after authorising. You will then come across a request such as:redirect_uri
for the initial redirect, but then the state
parameter as a second redirect which could contain the code
within the query parameters, or referer header.client_id
is perfectly fine and necessary, but leaking the client_secret
is dangerous. If this is leaked, the attacker can potentially abuse the trust and identity of the trusted client application to steal user access_tokens
and private information/access for their integrated accounts. Going back to our earlier example, one issue I’ve seen is performing this step from the client, instead of the server:code
, and using their application’s client_id
and client_secret
, will make a request from the server to retrieve an access_token
on behalf of you, which will allow them to access the permissions you consented to.client_secret
will be leaked and users will be able to generate access_tokens
on behalf of the application. With some social engineering, they can also add more scopes to the OAuth authorization and it will all appear legitimate as the request will come from the trusted client application.POST /oauth/token HTTP/1.1
...
``
grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=eyJhbGci...
GET /authorize?response_type=code%20id_token&client_id=sclient1&request_uri=https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt