Ошибка oauth что это такое

There are several cases where you may get an error response during authorization.

Errors are indicated by redirecting back to the provided redirect URL with additional parameters in the query string. There will always be an error parameter, and the redirect may also include error_description and error_uri.

For example,

https://example-app.com/cb?error=invalid_scope

Despite the fact that servers return an error_description key, the error description is not intended to be displayed to the user. Instead, you should present the user with your own error message. This allows you to tell the user an appropriate action to take to correct the problem, and also gives you a chance to localize the error messages if you’re building a multi-language website.

Invalid redirect URL

If the redirect URL provided is invalid, the authorization server will not redirect to it. Instead, it may display a message to the user describing the problem instead.

Unrecognized client_id

If the client ID is not recognized, the authorization server will not redirect the user. Instead, it may display a message describing the problem.

The user denies the request

If the user denies the authorization request, the server will redirect the user back to the redirect URL with error=access_denied in the query string, and no code will be present. It is up to the app to decide what to display to the user at this point.

Invalid parameters

If one or more parameters are invalid, such as a required value is missing, or the response_type parameter is wrong, the server will redirect to the redirect URL and include query string parameters describing the problem. The other possible values for the error parameter are:

invalid_request: The request is missing a required parameter, includes an invalid parameter value, or is otherwise malformed.

unauthorized_client: The client is not authorized to request an authorization code using this method.

unsupported_response_type: The authorization server does not support obtaining an authorization code using this method.

invalid_scope: The requested scope is invalid, unknown, or malformed.

server_error: The authorization server encountered an unexpected condition which prevented it from fulfilling the request.

temporarily_unavailable: The authorization server is currently unable to handle the request due to a temporary overloading or maintenance of the server.

In addition, the server may include parameters error_description and error_uri with additional information about the error.

Application suspended

If the OAuth App you set up has been suspended (due to reported abuse, spam, or a mis-use of the API), GitHub will redirect to the registered callback URL using the following parameters to summarize the error:

http://your-application.com/callback?error=application_suspended
  &error_description=Your+application+has+been+suspended.+Contact+support@github.com.
  &error_uri=/apps/building-integrations/setting-up-and-registering-oauth-apps/troubleshooting-authorization-request-errors/%23application-suspended
  &state=xyz

To solve issues with suspended applications, please contact GitHub Support.

Redirect URI mismatch

If you provide a redirect_uri that doesn’t match what you’ve registered with your application, GitHub will redirect to the registered callback URL with the following parameters summarizing the error:

http://your-application.com/callback?error=redirect_uri_mismatch
  &error_description=The+redirect_uri+MUST+match+the+registered+callback+URL+for+this+application.
  &error_uri=/apps/building-integrations/setting-up-and-registering-oauth-apps/troubleshooting-authorization-request-errors/%23redirect-uri-mismatch
  &state=xyz

To correct this error, either provide a redirect_uri that matches what you registered or leave out this parameter to use the default one registered with your application.

Access denied

If the user rejects access to your application, GitHub will redirect to
the registered callback URL with the following parameters summarizing
the error:

http://your-application.com/callback?error=access_denied
  &error_description=The+user+has+denied+your+application+access.
  &error_uri=/apps/building-integrations/setting-up-and-registering-oauth-apps/troubleshooting-authorization-request-errors/%23access-denied
  &state=xyz

There’s nothing you can do here as users are free to choose not to use
your application. More often than not, users will just close the window
or press back in their browser, so it is likely that you’ll never see
this error.

 Here we list the most common errors encountered in Rabobank OAuth 2.0 flow on the client side. These use cases list reason for errors and how to troubleshoot them.

During the Authorization call to get the consent of the user, the TPP may encounter the following:

Invalid client id supplied

You receive an HTTP response of 401 Unauthorized with the message invalid client id or secret while invoking an Authorization flow.

This could be caused by one of the following:

1. Invalid client id is supplied in the request.
2. Your TPP application is not subscribed to an API using OAuth 2.0.

To solve this issue, your application should be subscribed to an API using OAuth 2.0 and provide a valid client ID.

Redirect URI mismatch

When registering an application, you should provide a redirect URI on the Rabobank developer portal.

If you have more than one redirect URLs listed in the developer portal, make sure to provide one of the redirect URI (as provided during registration) in the redirect_uri query parameter during an Authorization call. If the redirect URI from your request does not match with the one registered on the Rabobank developer portal, you get the following error:

Requesting access token

To access the requested resources, you should exchange the received authorization code for an access token. During the retrieval of the access token, you may encounter the following:

Invalid authorization code (grant type code flow)

The authorization code should be sent to the token endpoint to get the access token. Sending an invalid authorization code (expired, invalid, or already used) results in the below error:

Http status: 400 (Bad request)
{"error": "invalid_grant"}

To avoid this error, you should pass the correct authorization code before it expires (expiry: 5 minutes). Make sure to not call the token endpoint multiple times using the same authorization code.

Adding a slight delay of 1000ms before calling this endpoint ensures that the authorization code is in sync across our servers.

Invalid refresh token

Sending invalid Refresh token to get access token results in the below error:

Http status: 401 (Unauthorized)
{"error": "invalid_grant"}

The Refresh token is valid for 30 days and can be only used once. To avoid this error, you should pass a valid Refresh token and not use the same token multiple times.

Invalid authorization header

While making a call to the token endpoint, an Authorization header should be provided consisting of a client id and client secret. If an invalid combination is passed, it results in the below error:

Http status: 401 (Unauthorized)
{"error": "invalid_client"}

To avoid this error, you should use the correct client id and client secret and make sure that the Authorization header is prepared as specified in the OAuth documentation.

Grant type missing

While making a call to the token endpoint, the grant_type query parameter should be provided. The value of this query parameter is based on the type of authorization you are passing to the endpoint.

For example, if you are swapping an authorization code for an access token the value of the parameter should be the authorization_code.

An example of the error message returned is as below:

Http status: 400 (Bad request)
{"error": "invalid_request"}

To avoid this error, make sure to provide all the required parameters, including grant_type.

Requesting resources with an access token

Access token invalid

The Access token issued by the authorization server is valid for 60 minutes for PSD2 and 24 hrs for Premium after receiving. Passing an expired or invalid Access token while accessing the resource results in the following error.

{
  "httpCode": "401",
  "httpMessage": "Unauthorized",
  "moreInformation": "This server could not verify that you are authorized to access the URL"
}

To avoid this error, you should always check the expiry time associated with the access token. If the token is expired, use a Refresh token to receive a new Access token.

If you are unable to get a new access token using the refresh token, it could be because the user consent is either expired or revoked. You can validate the consent using the Consent Details Service API.

If this is the case, you should renew the consent before proceeding.

How to check if the user consent is expired (or) revoked?

Using the information you received during the authorization flow, you can retrieve the consent by a specific Id as explained in the API Consent Details Service documentation.

If the consent status is one of the following, the consent is not valid and cannot be used to access the resources:

• expired
• revokedByPsu
• terminatedByTpp
• received
• rejected

Using an invalid consent results in the following error:

{
  "httpCode": "403",
  "httpMessage": "Forbidden",
  "moreInformation": "CONSENT_INVALID"
}

To access the resource gain, you should follow the authorization flow again and ask the user permission(s) to the required resources.

Deactivated or Expired consent

The consent of the user may be expired or revoked by the user, while your access/refresh tokens are still active, this results in a 403 Forbidden CONSENT_INVALID error message.

Not having the required permission to access an API

{  
  "httpCode": "403",  
  "httpMessage": "Forbidden",  
  "moreInformation": "FORBIDDEN"
}

A 403 Forbidden FORBIDDEN error can be triggered if the Access token included in the request does not contain the correct scope for the API being used.

Example: You have an access token for the scope paymentRequest, but you are trying to access the Account information API, this API requires a different scope: ‘ais.balances.read’.

To avoid this error, follow the authorization flow with the correct scope required for your API.

The authorization server responds with HTTP 400 or 401 status codes. Here, two cases take place, if an error occurs during the authorization. In the first case, the client is not identified or recognized. In the second case, something else fails in spite of the client being identified exactly. In such a case, an error response is sent back to the client as follows −

• error_description − It is an optional human readable error description in a language specified by Content-Language header, which is meant for the developer and not the end user.

• error_uri − It is an optional link to a human-readable web page along with information about an error that can be helpful for problem solving.

• error − It is a set of predefined error codes.

Following is the description of error codes and equivalent HTTP status codes.

400 Errors

The following table shows 400 errors with description.

401 Errors

The following table shows 401 errors with description.

oauth2.0_client_credentials.htm