Using AccessProviders other than Auth0 or Okta

Hi there, really happy to see third party auth moving to the individual plan! That prompted me to give Fauna a serious look again.

I ended up going the path of issuing my own JWT access tokens rather than relying on Auth0 or Okta, and was hoping to use my own IDP as a third party auth provider to integrate with Fauna. When I tried to set up an AccessProvider for third party auth through the dashboard however, I ended up getting this error on the JWKS endpoint field:

Please enter a valid Auth0 or Okta URL

Does this mean only Auth0 and Okta are officially supported at the moment? Any particular reason for this? As far as I understand, the process for verifying JWTs should be identical as long as the issuing IDP exposes their public keys in the correct format at their jwks endpoint.

Also, interestingly enough, I was able to bypass the error by calling CreateAccessProvider in the shell, but I wasn’t able to figure out how to associates roles with the AccessProvider after creating it, and attempting to update roles in the dashboard results in the same error message above.

Any ideas on how to proceed would be appropriated.

Thanks!
Lewis.

1 Like

Hi @lewisl,

Yes, you are correct: currently the only auth providers guaranteed to work with Fauna are Auth0 and Okta. This is mainly because, even though the format for JWTs is well documented, not all providers use exactly the same claims. We have tested using both Auth0 and Okta, so we can definitively state they work with our service. For the time being, those two are hard-coded into Fauna, so other providers are not yet supported.

We are always looking for user feedback for future features, though, and which auth providers to support is one of those. A quick search of our Feature Requests board didn’t turn up specifically around JWTs, but if you’d like to post one there our Product team can use that to help guide future enhancements to Fauna.

Thanks,
Cory

It’d be great if you could even just turn the UI validation on the JWKS endpoint field to a non-blocking warning instead of a blocking error. That would at least unblock usage and experimentation with custom JWTs. Currently my integration is completely blocked because of this very superficial UI limitation, and I’ll probably end up having to settle with another provider as a result.

Would be awesome if you could also take some time to document which claims Fauna depends on, but even without that I could at least probably try to replicate the auth0 claims as much as possible in my own JWTs and try to make something work.

Update: Upon a closer look at the docs, I found this:

To work with Fauna, a JWT must, at minimum, include the iss , sub , and aud claims.

This seems to suggest that the iss sub and aud claims are the claims required? If that’s the case my tokens should already be compatible as is.

I agree that being able to support other auth providers would be a great improvement. As things stand now, though, Auth0 and Okta are still the only options hardcoded into the Fauna service as auth providers. Those are the ones we’ve tested against, and those are the ones we know will work, so those are the two we’ve made available in the service.

Ideally yes, we would love to be able to support any and all auth providers, including home grown ones. But auth misconfigurations can lead to all kinds of pain, including getting accounts locked out, so we have to be cognizant of that danger and put in appropriate guardrails to prevent it from happening.

We do have a roadmap item to extend this functionality so that developers can roll their own auth provider. We can’t say for sure when that will be available, though, as it’s dependent on some other features being completed, first.

Hi @lewisl please stay tuned. We plan to lift this constraint in the near future, and I’ll be sure to update this thread when that work is complete.

I am really interested in this, happy to test it out (just building a POC around JWTs, not production use)