OAuth 2.0 Token Exchange (RFC 8693) #437
Labels
area/api
area/implementation
kind/enhancement
New feature or request
kind/investigation
size/medium
status/discussing
Further information is requested
Authorino does not provide any built-in functionality for obtaining OAuth2 access tokens on behalf of clients trying to access a service that is protected by an AuthConfig. This is by design to not violate a principle of the OAuth2 protocol, apart from a good practice of application security in general, according which each client is responsible for managing its own access tokens and credentials.1
Users of Authorino nevertheless often look out for ways of leveraging the flexibility provided by the authorization service, to handle the flows for obtaining and the management of access tokens. A lightweight example of this, that may not involve storing client authentication secrets in the AuthConfig, is relying on built-in OPA support or HTTP GET/GET-by-POST metadata to simply refresh an access token previously obtained by the client by its own means.
Example: OAuth2 token refresh performed by Authorino
Follow the steps ① to ④ of the OpenID Connect Discovery and authentication with JWTs user guide. Then, create the following AuthConfig that uses the refresh token passed in a
Request-Token
HTTP request header to exchange it on behalf of the client for a new access token.Instead of handling the OAuth2 grant/OIDC flows on behalf of the clients – a functionality more directly provided by solutions such as OAuth2 Proxy and Envoy's OAuth2 filter – Authorino implemented its own built-in Security Token Service (STS), called Festival Wristband.
Clients can exchange tokens – including tokens not limited to OIDC-issued JWTs (OAuth2 opaque tokens, API keys, etc) – for a highly customizable new JWT that the Authorino instance itself provides the keys to verify. This solution is particularly useful for implementing Edge Authentication Architecture (EAE) and applications in general that require reducing the scope of access tokens, avoid sharing tokens across services, etc.
Although it doesn't replace the need by the clients to handle the initial OIDC flow when that is the method of choice for authentication, Authorino's Festival Wristband tokens do provide an alternative to managing and to refreshing secondary tokens issued under the new scope. On the flip side, Authorino loses transparency in the identity management flow and becomes a token issuer authority.
Aiming to delegate the responsibility of issuing the wristband tokens to a proper authentication server and thus avoiding Authorino becoming a central actor in the identity management flow, this feature was proposed to be extended.
Since the OAuth 2.0 Token Exchange protocol (RFC 8693) became a standard, it opened up new possibilities for the implementation of the aforementioned proposal – if not to fully replace the feature.
One important aspect of OAuth 2.0 Token Exchange though is its built-in support for impersonation, which means, if adopted, that Authorino would lose transparency in the process of obtaining the new token, but (i) without becoming a central piece of the identity management flow – i.e., without becoming a token issuer authority – and (ii) by sticking with a proper industry protocol for the purpose of exchanging tokens. Some flexibility to define claims that end up in the new token may be lost.
Token Exchange can also be key to avoid sharing tokens across services, while it may require Authorino to keep track (occasionally refreshing) its own tokens on the other hand.
Footnotes
For Security Considerations of the OAuth2 protocol, see Section 10 of RFC 6749. ↩
The text was updated successfully, but these errors were encountered: