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

Version management

Difference between version and

At line 1 added 22 lines
!!! Overview[1]
[{$pagename}] describes [Transport Layer Security] ([TLS]) [Mutual Authentication] using [X.509] [certificates] as a mechanism for both [OAuth Client] [authentication] to the [token_endpoint] as well as for sender constrained access to [OAuth 2.0] [Protected Resources].
The [OAuth 2.0] Authorization Framework [RFC 6749] defines a [Shared Secret] method of [OAuth Client][authentication] but also allows for the definition and use of additional client [authentication] mechanisms when interacting with the [Authorization Server]'s [token_endpoint].
!! [OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]
[{$pagename}] describes an additional mechanism of client utilizing [mutual Authentication] [TLS] [RFC 5246] [certificate]-based [authentication], which provides a higher [Level Of Assurance] and better security characteristics than [Shared Secrets].
!! [Mutual TLS Sender Constrained Resources Access]
[Mutual|Mutual Authentication] [TLS] sender constrained access to [Protected Resources] ensures that only the party in possession of the [Private Key] corresponding to the [certificate] can utilize the [Access Token] to get access to the associated [Protected Resources]. Such a constraint is unlike the case of the basic [Bearer Token] described in [RFC 6750], where any party in possession of the [Access Token] can use it to access the associated [resources]. [Mutual|Mutual Authentication] [TLS] sender constrained access __prevents__ the use of stolen [Access Tokens] by binding the [Access Token] to the client's [certificate].
[Mutual TLS for OAuth Client Authentication|OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens] and [Mutual TLS Sender Constrained Resources Access] are distinct mechanisms that don't necessarily need to be deployed together.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Mutual TLS Profiles for OAuth Clients draft-ietf-oauth-mtls-04|https://tools.ietf.org/html/draft-ietf-oauth-mtls-04|target='_blank'] - based on information obtained 2017-07-29
* [#2] - [Mutual TLS Profiles for OAuth Clients draft-ietf-oauth-mtls-05|https://tools.ietf.org/html/draft-ietf-oauth-mtls-05|target='_blank'] - based on information obtained 2017-11-12
* [#3] - [OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens draft-ietf-oauth-mtls-06|https://tools.ietf.org/html/draft-ietf-oauth-mtls-06|target='_blank'] - based on information obtained 2018-01-15
* [#4] - [OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens draft-ietf-oauth-mtls-07|https://tools.ietf.org/html/draft-ietf-oauth-mtls-07|target='_blank'] - based on information obtained 2017-07-29
* [#5] - [OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens draft-ietf-oauth-mtls-08|https://tools.ietf.org/html/draft-ietf-oauth-mtls-08|target='_blank'] - based on information obtained 2018-05-06