This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Access Token Validation
Access Token Validation

Version management

Difference between version and

At line 1 added 386 lines
!!! Overview
[{$pagename}] is dependent on the [Grant Type]
!! [{$pagename}] [OAuth 2.0]
[OAuth Client] sees the [Access_token] is an Opaque [entity] and no [validation] is performed.
[OAuth 2.0 Token Introspection] ([RFC 7662]) defines a [protocol] that allows authorized protected resources to query the [Authorization Server] to determine the set of [metadata] for a given [Access Token] that was presented to them by an [OAuth Client]. This [metadata] includes whether or not the [token] is currently active (or if it has expired or otherwise been revoked), what rights of access the token carries (usually conveyed through [OAuth Scopes]), and the [authorization] context in which the token was granted (including who authorized the token and which [OAuth Client] the [Token] was issued to). [OAuth 2.0 Token Introspection] allows a protected resource to query this information regardless of whether or not it is carried in the token itself, allowing this method to be used along with or independently of structured token values. Additionally, a protected resource can use the mechanism described in this [OAuth 2.0 Token Introspection] to introspect the [token] in a particular authorization decision context and ascertain the relevant [metadata] about the [token] to make this [authorization] decision appropriately.
[OAuth 2.0 Token Introspection] ([RFC 7662]) defines a method for a [Resource Server] to query an [OAuth 2.0] [Authorization Server] to determine the active state of an [OAuth 2.0] [access_token] and to determine meta-information about this [token].
[Resource Server] [MUST] validate the [Access_token] and ensure that it has not expired ([exp]) and that its [OAuth Scopes] covers the requested [resource].
!! [{$pagename}] [OpenID Connect]
To validate an Access Token issued from the Authorization Endpoint with an ID Token, the Client SHOULD do the following: [1]
* [Hash] the octets of the [ASCII] representation of the [access_token] with the hash algorithm specified in [JWA] for the alg Header Parameter of the [Id_token]'s [JOSE Header]. For instance, if the [alg] is [RS256], the hash algorithm used is [SHA-256].
* Take the left-most half of the [hash] and [base64url] encode it.
* The value of [at_hash] in the [Id_token] [MUST] match the value produced in the previous step.
!! [{$pagename}] and [Grant Types] [2]
* [Implicit Grant], if the [id_token] contains an [at_hash] [Claim], the [Client] [SHOULD] use it to validate the [Access Token] ([Access_token])
* [Authorization Code Grant], if the [id_token] contains an [at_hash] [Claim], the [Client] [MAY] use it to validate the [Access Token] ([Access_token])
* [Hybrid Flow], if the [id_token] contains an [at_hash] [Claim], the [Client] [SHOULD] use it to validate the [Access Token] ([Access_token])
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [3.2.2.9. Access Token Validation|http://openid.net/specs/openid-connect-core-1_0.html#ImplicitTokenValidation|target='_blank'] - based on information obtained 2018-03-02-
* [#1] - [3.1.3.8. Access Token Validation|http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowTokenValidation|target='_blank'] - based on information obtained 2018-03-02-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop