RFC8693 OAuth 2.0 Token Exchange

Feedback
,
1

Feature:
RFC8693 OAuth 2.0 Token Exchange implementation.

Description:
The feature request is the implementation of the RFC8693, with the ability to configure custom authorization logic and token mapping.

Use-case:
While working on enterprise systems, you will find yourself trying to integrate multiple authentication solutions, and they might be proprietary solutions, sometimes not even JWT based, where an HTTP request to a private endpoint is required to introspect the token and obtain details about the user.

In those mixed conditions, having a way to translate those proprietary tokens into a common and standard token (thinking of a JWT access token) and vice-versa is required to simplify the authentication/authorization layers of the system. All without asking the user to login into several platforms. The RFC cover more uses cases, but that is the one we are interested in.

Just searching on the forum I could see interest in the topic and even messages talking about the work has been started already, but I cannot find any pieces of evidence of it being complete:

2

Hi @joseandrespg,

Thanks for reaching out to the Auth0 Community and creating this detailed feedback request.

Let’s hope it attracts as many votes as possible to support the OAuth 2.0 Token Exchange.

Have a great rest of your day.

Thank you.

1 Like
3

We’re migrating from Keycloak which supports token exchange, and this is one major piece we’re going to need to rebuild internally.

4

I talked with our product team about that and it seems that the work is in progress! Once I know more I will reopen the topic and let you know about that!

That was Jan 2020… when is this feature coming, as without delegation being available, the only focus that Auth0 seem to have is single client->api architectures, but in the real world we live with more than 1 api in more than 1 layer, so any kind of propertly supported delegation of users would be appreciated.

1 Like
5

In a case as ours, when trying to build central authentication service as an auth umbrella for multiple disjoint products usin A0, tokens exchange seems to be a crucial part of such solution.

One could rely on A0 session and use prompt=none with different audience values to try to mimic such token exchange. This comes with nontrivial dev effort in FE and BE of all integrated products.

One could build own, internal tokens exchange/sts but then we get heterogenous on authorization, allowing both A0 issued/signed and internally issued/signed authZ.

Implementation of mentioned spec could be the answer to the challenge.

6

I’d really love to see this implemented.
The suggested approach of using a “single logical API” to represent multiple micro-service APIs definitely does not feel like best practice.
This article has a great explanation of why Delegation Patterns for OAuth 2.0 using Token Exchange

1 Like