Hi!
Does anybody know of an auth0 feature that replaces clientid/secret with signed JWT’s to obtain access tokens?
I’ve searched the docs (and the community forum) but was unable to find anything useful.
And the auth0 settings of my tenant also doesn’t seem to provide an option to provide a public key entry field.
Our identity provider we’re forced to use enforces this RFC 7523 on us, and we’d love to try it out while they’re still setting up environments etc. on their end.
Thanks in advance!
Hey there @Sch3lp, unfortunately we have no support for RFC 7523 at the moment and not projected to add it in the near future. When leveraging machine to machine auth, we only support the client credentials grant which makes use of the client id and secret. Please let me know if this helps answer your question. Thanks in advance.
This does answer my question. Thanks for answering James!
You did make me curious to learn about the reasoning behind not supporting RFC 7523. If you can share something about that, that should be an interesting read.
After checking with our team it appears that support for RFC 7523 just hasn’t’ been built out yet, no negative association. However we would love to find out more details about your specific use case, whether through the topic here or in a DM. Also please visit Auth0: Secure access for everyone. But not just anyone. and make your request along with your specific details there as well. This data allows us to gauge the need for RFC 7523 in our future timelines. Thanks again!
Sorry for the late response, we’re a bit time-constrained (who isn’t, amirite?).
Our use case is the following:
We’re a feature team that has to integrate with a specific Identity Provider (from belgian government), so our application can be allowed to send data over their service bus. This service bus is another constraint our application needs to adhere to since we’re sending confidential data to be shared with other government instances and health providers.
Our application redirects to their IDP so we can get an access token, which we then can exchange for a SAMLToken that we can use to call their service bus.
This IDP works exclusively with RFC7523 authentication, but the company behind it isn’t very responsive, so we were looking for alternatives to try and get some early feedback on whether or not our implementation on our end would work (like I said, we’re a bit time-constrained).
Eventually we set up our own KeyCloak instance that we managed to configure with RFC7523 etc. and got our early feedback that way.
So specifically, the need for us was to get a temporary IDP that supports RFC7523 so we could test our own implementation against it. There are no future plans to move to auth0 for example where RFC7523 is a requirement.
Sorry again for the late response.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.