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:
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.
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.
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
Adding another use case here:
We need this feature to handle our large amount of service accounts efficiently. All our workloads have service accounts to grant them access to apis, currently we are using the client credential grant. However this comes with a high cost in M2M tokens especially for short lived workloads. And also it is not good for security to have that many credentials all over the place. Caching doesn’t make sense because then we need to store secrets in even more places.
Instead we want to leverage kubernetes service account tokens to verify workload identities and exchange workload id tokens for access tokens issued by Auth0 for our apis.
Howdy folks,
I’ve heard through our sales contact that this feature is set for Q3 2024. Is there any updates on whether it’ll be done or picked up in 1 month from now?
This is in fact a blocker to our adoption of Auth0, so we’re trying to see how to time this.
Would also love to see this; I have implemented this in PingFederate at a client, and this is a crucial feature both for Kubernetes but also for CI/CD systems like Github Actions and GitlabCI