Hannes,
> today I submitted a short document that illustrates the concept of
> holder-of-the-key for OAuth.
> Here is the document:
> https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk
A different approach would be for the service to issue a private asymmetric key
to the client app, along with a certificate, in the access token response. This
is a slightly better match to the OAuth2 model of the authorization service
issuing temporary credentials for accessing resources on a user’s behalf.
When the token_type is "tls_client_cert" (probably a better label than "hotk"),
the client can access protected resources using TLS with client authentication;
using the key from the "private_key" field. The "access_token" field holds a
base64url-encoded certificate to include in the TLS handshake.
An example access token response could be:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"token_type":"tls_client_cert",
"access_token":"MIIGcDCCBdmgAwIBAgIKE…",
"private_key":{
"alg":"RSA", "mod":"Ovx7…", "p":"7dE…", "q":"fJ3…", …
},
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
The suggestion above passes the "access_token" to the protected resource in the
TLS protocol in the form of a certificate.
draft-tschofenig-oauth-hotk says the client "presents the access token to the
resource server", but it wasn't clear to me how it was done. Were you expecting
the client to use the BEARER HTTP auth scheme inside the client-authenticated
TLS connection?
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
