Resource Owner- an entity that can grant access to a protected resource; typically this is the end-user.
Resource Server- the server hosting the protected resources; this is the API you want to access.
Client- an application requesting access to a protected resource on behalf of the resource owner.
Authorization Server- the server that authenticates the resource owner, and issues access tokens after getting proper authorization.
response_type- tells the authorization server which grant to execute.
client_id- the id of the application that asks for authorization.
redirect_uri- holds a URL; a successful response from this endpoint results in a redirect to this URL.
scope- a space-delimited list of permissions that the application requires.
state- is a parameter that allows you to restore the previous state of your application; the
stateparameter preserves some state object set by the client in the authorization request and makes it available to the client in the response.
response_typerequest parameter is used to inform the authorization server which grant type to use:
code- value to use authorization code grant.
token- value to use implicit grant.
password- value to use resource owner password credentials grant.
client_credentials- value to use client credentials grant.
stateparameter. The client implements CSRF protection by checking that the
stateexists in the user's session when he comes back to get the
stateparameter in this design is a key to a session attribute in the authenticated user's session with the client application.
code- is the authorization code received from the authorization server.
grant_type- is a parameter that explains what the grant type is, and which token is going to be returned.
client_secret- is a secret known only to the application and the authorization server.
Loginwithin the regular web application.
stateparameters (see also additional information about the authorization response):
codeand its own
client_secretwill make a request for
access_token(see also additional information about the access token request):
access_tokento access the user's data (see also additional information about the access token response).
Loginwithin the regular web application
redirect_urispecified in the authorization request. However, instead of sending a query parameter containing an authorization code, it will send the access token and other token-specific data as a URL fragment (see also additional information about the access token response):
access_tokenfrom the URL fragment, it can use it to access the user's data.
access_tokenmatches the other data in the request. In this case, an attacker can simply change the parameters sent to the server to impersonate any user.
access_token(step 5) is executed from the client, instead of the server.
redirect_uriin case of an error, for example, due to an incorrect scope value. In this case, an attacker crafts the following link:
access_tokenallows making requests to the API, it is worth checking whether it is possible to abuse this. Sometimes the granted rights to
access_tokenallows you to release new tokens with increased privileges or get access to additional functionality available only with session token.
Hostheader can lead to account takeover not only during password recovery but also OAuth authentication. Sometimes you can affect
redirect_uriby poisoning the
Hostheader. As a result, when the victim exchanges the authorization code for access token, he / she will send a request with this token to your domain. Example of vulnerable request:
amr_valuesparameters and use them to process the authentication request.
amr_values(or authentication method reference values) specifies authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used.
acr_values(or requested authentication context class reference values) specifies a set of business rules that authentications are being requested to satisfy. These rules can often be satisfied by using a number of different specific authentication methods, either singly or in combination.
amr_values=pwd+otp, you can try to bypass two-factor authentication by passing
client_id, which poisons the session.
redirect_uriof the "untrusted" client.
redirect_uriand leak a token to it.
prompt=consentparameter, which you can append to the URL of the authorization request to potentially bypass this problem. If the server follows OpenID Connection specification, it should ask the users for confirmation of their consent even if they have previously granted it. Without confirmation, the exploitation is harder but still possible, depending on the particular OAuth server implementation.
read:emailscope. After the user approves this request, the malicious client application receives an authorization code. As the attacker controls their client application, they can add another scope parameter to the code exchange request containing the additional profile scope:
access_tokenusing the new scope and send this to the attacker's client application.
access_tokenis sent via the browser, which means 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 requests to the authorization service's endpoints, manually adding a new scope parameter in the process.
redirect_uriis very important because sensitive data, such as the
code, is appended to this URL after authorization. If the
redirect_urican be redirected to an attacker controlled server, this means the attacker can potentially takeover a victim's account by using the code themselves.
localhostin a production environment: