29.06.2021 | Thomas Bühler
Modern Authentication - Token Exchange
Modern authentication protocols have become indispensable in the age of the cloud and increasing cross-site collaboration. After Kerberos had set the benchmark in the on-premise world for decades, OASIS adopted SAML V1.0 in 2002, enabling standardized SSO integration of web applications for the first time. In 2005, Brad Fitzpatrick and Johannes Ernst introduced the world to OpenID Connect as another web SSO protocol. From then on, the two web SSO processes and the still widely used legacy protocols existed side by side.
Modern, hybrid IT network system approaches require interaction via a multi-protocol single sign-on infrastructure, which must guarantee the seamless transfer of authentication information. Until now, developers have been forced to develop their own solutions for this task. The approaches range from embedding Kerberos tickets in the authentication statements of a SAML assertion to numerous proprietary concertation services.
First standardization through RFC 8693
In January 2020, RFC 8693 OAuth 2.0 Token Exchange was published by Microsoft, Ping Identity, Yubico and Visa via the Internet Engineering Task Force (IETF). It contains a solution approach that enables the seamless conversion of security tokens. This is particularly interesting as the trend is increasingly moving away from the SOAP-WS Trust world of OASIS towards web developments with RESTful patterns (Representational State Transfer) and JSON. The OAuth 2.0 Authorization Framework and the associated OAuth 2.0 Bearer Tokens are increasingly being used for the http-based authorization of third-party access to RESTful resources, as the protocol is more suitable for mobile use cases and is generally leaner and more flexible.
As part of the conversion process in accordance with RFC 8693, the newly introduced Security Token Service (STS) validates the information and responses provided to it with a replacement token. This enables clients to access resources in heterogeneous environments or across security domains. The service is controlled via a protocol extension of the OAuth 2.0 standard, which uses existing communication patterns and data formats familiar to most RESTful developers.
The token exchange request serves as the starting point for the conversion process. The client sends a corresponding request to the token endpoint with a special extension type using the HTTP POST method. Using grant_type urn:ietf:params:oauth:grant-type:token-exchange, the service is informed that a token is to be exchanged. For serialization based on JavaScript Object Notation (JSON), the subject_token parameter must contain the identity of the party and the subject_token_type parameter must reference the type of existing security token. Optionally, further values such as resource, audience, scope, requested_token_type, actor_token and actor_token_type can be passed, which are then prioritized during the conversion.
If the request was placed correctly with the STS, it responds by returning an access token via the parameter with the same name, access_token. The usual OAuth 2.0 responses from the token endpoint are used here, as is already known from other OAuth processes.
In the response, the client is first informed of the technological reference of the response token via issued_token_type and the deployment method to be used via token_type. The special feature here is that returned tokens do not have to be OAuth access tokens. Any tokens can be returned for any login procedure, provided that the token endpoint is designed for this and has the technical requirements and corresponding network integration. Other values such as expires_in, scope and refresh_token can be configured on the token endpoint in order to override the original values on a case-specific basis. The legitimacy of the request on the token endpoint must be checked in each case.
Conclusion and status of implementation
The procedure described in RFC 8693 OAuth 2.0 Token Exchange offers an interesting option for the standardized exchange of tokens in a direct procedure. In addition, proprietary solutions are still available, such as the use of SPNEGO-based Kerberos Authentications to automate the registration of an OAuth 2.0 Authorization Code Flow on the identity provider.
ZITADEL from the Swiss company CAOS AG and Ping Identity as a global provider currently support the OAuth 2.0 Token Exchange in accordance with RFC 8693. Auth0 is planning to implement this this year. Red Hat Keycloak currently has its own solution based on web services, but has announced that it will also support the RFC 8693 standard in the future.
So it remains exciting to see how the young standard will develop. We at Temet will stay tuned and keep you up to date.
Identity Federation Security Architecure Strong Authentication
