The API can then check if the client certificate from the TLS session matches the one in the token by comparing the thumbprint. The client presents the same certificate that it used to authenticate to the authorization server. When the client requests the protected resources at the resource server (API) with a Mutual TLS Sender Constrained Tokens it will be forced to establish a mutual TLS session.
The token includes the certificate thumbprint in the confirmation claim cnf. The following figure shows an example of a Certificate-Bound Access Token. After a successful client authentication the authorization server will encode the thumbprint (hash) of the client certificate either directly in the token (JWT) or in the Introspection Response (when using opaque tokens). The TLS session is established by the Mutual TLS Client Authentication as part of a OAuth 2.0 workflow.
Mutual TLS Sender Constrained Tokens are tokens that are bound to the underlying mutual TLS connection between the client and the authorization server. Certificate-Bound Access Tokens are an example of such tokens and we refer to them as Mutual TLS Sender Constrained Tokens. The resource server cannot determine if the sender of a Bearer token is legit or not as long as the token is valid.Ī solution to this problem are Holder-of-Key Tokens or Proof-of-Possession Tokens where the resource server can verify that the sender of a token is the same entity whom the token was issued for. That means that if a Bearer token gets into the hands of unauthorized actors, they can impersonate the user and get unauthorized access to the protected resources. Presenting a valid Bearer token is proof enough for gaining access.
One of the main vulnerabilities of OAuth are Bearer tokens.
0 kommentar(er)
