invalid_
Registry Context
`invalid_token` is the bearer-token error value used in resource access error responses when the provided access token is expired, revoked, malformed, or otherwise invalid.
Technical Summary
RFC 6750 registers `invalid_token` for resource access error responses associated with the bearer access token type. It identifies a provided access token that is expired, revoked, malformed, or invalid for another reason.
When Used
When a protected resource request provides an expired, revoked, malformed, or otherwise invalid access token.
Normative Requirements
Clients
RFC 6750 - Section 3.1
request a new access token and retry the protected resource request.
Condition: after receiving an `invalid_token` error
The client MAY request a new access token and retry the protected resource request
Resource servers
RFC 6750 - Section 3
include any of the `error`, `error_description`, or `error_uri` attributes more than once.
Condition: when constructing a bearer challenge
The "error", "error_description", and "error_uri" attributes MUST NOT appear more than once
RFC 6750 - Section 3
include characters outside `%x20-21 / %x23-5B / %x5D-7E` in `error` or `error_description` attribute values.
Condition: when constructing a bearer challenge
MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E
RFC 6750 - Section 3
include the `WWW-Authenticate` response header field.
Condition: when the protected resource request does not contain an access token that enables access to the protected resource
the resource server MUST include the HTTP "WWW-Authenticate" response header field
RFC 6750 - Section 3
use the `Bearer` authentication scheme for the challenge.
Condition: when issuing a challenge defined by RFC 6750
All challenges defined by this specification MUST use the auth-scheme value "Bearer"
RFC 6750 - Section 3
follow the `Bearer` authentication scheme with one or more authentication parameters.
Condition: when issuing a bearer challenge
This scheme MUST be followed by one or more auth-param values
RFC 6750 - Section 3
include the `error` attribute in the `WWW-Authenticate` response header field.
Condition: when the protected resource request included an access token and failed authentication
the resource server SHOULD include the "error" attribute
RFC 6750 - Section 3.1
respond with HTTP 401 (Unauthorized).
Condition: when the provided access token is expired, revoked, malformed, or invalid for another reason
The resource SHOULD respond with the HTTP 401 (Unauthorized) status code
RFC 6750 - Section 3
include the `error_description` attribute with a human-readable explanation intended for developers.
Condition: when returning a bearer authentication error
the resource server MAY include the "error_description" attribute
RFC 6750 - Section 3
include the `error_uri` attribute with an absolute URI identifying a human-readable explanation of the error.
Condition: when returning a bearer authentication error
It also MAY include the "error_uri" attribute
Validation Guidance
For an invalid token that does not enable access, require a `WWW-Authenticate` response header field.
Require the challenge to use the `Bearer` scheme followed by at least one authentication parameter.
When a provided access token fails authentication, expect the bearer challenge to include `error="invalid_token"`.
Allow `error_description` and `error_uri` to accompany `invalid_token`; do not require either attribute.
Reject duplicate `error`, `error_description`, or `error_uri` attributes in a bearer challenge.
Reject `error` and `error_description` values containing characters outside the permitted character set.
Expect HTTP 401 when the response reports `invalid_token`.
Clients may obtain a new access token and retry after receiving `invalid_token`.
Reference
Details
- Entry Id
invalid_token - Name
invalid_token - Usage Location
resource access error response- Protocol Extension
bearer access token type- Change Controller
IETF- Reference
RFC6750