access token.scopes.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 state parameter preserves some state object set by the client in the authorization request and makes it available to the client in the response.response_type request 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.state parameter. The client implements CSRF protection by checking that the state exists in the user's session when he comes back to get the access_token. The state parameter 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.Login within the regular web application.redirect_uri with the code and state parameters (see also additional information about the authorization response):code and its own client_id and client_secret will make a request for access_token (see also additional information about the access token request):access_token to access the user's data (see also additional information about the access token response).Login within the regular web applicationredirect_uri specified 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_token from the URL fragment, it can use it to access the user's data.access_token is sent from the authorization service to the client application via the user's browser as a URL fragment. The client application then accesses the token using javascript. The trouble is, if the application wants to maintain the session after the user closes the page, it needs to store the current user data (normally a user_id and the access_token) somewhere.access_token matches the other data in the request. In this case, an attacker can simply change the parameters sent to the server to impersonate any user.state parameter is:access_token (step 5) is executed from the client, instead of the server.redirect_uri in case of an error, for example, due to an incorrect scope value. In this case, an attacker crafts the following link:access_token allows making requests to the API, it is worth checking whether it is possible to abuse this. Sometimes the granted rights to access_token allows you to release new tokens with increased privileges or get access to additional functionality available only with session token.Host header can lead to account takeover not only during password recovery but also OAuth authentication. Sometimes you can affect redirect_uri by poisoning the Host header. 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:acr_values or amr_values parameters 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 amr_values=pwd.client_id.client_id, which poisons the session.redirect_uri of the "untrusted" client.redirect_uri and leak a token to it.prompt=consent parameter, 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:email scope. 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_token using the new scope and send this to the attacker's client application.access_token is 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_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.localhost in a production environment:Referer header: