The company I work for just switched to custom domains for all our authentication logic and that created a bunch of issues that we are now trying to resolve. As we use multi-tenant approach and will end up with roughly 10+ tenants in the end we need a sensible solution to maintain tenants, rules and hooks up. The problems that we are facing are:
Q1: Hooks are currently not supported by the GitHub Extension - is there a roadmap or estimated date?
Q2: The “iss” claim in the tokens - one of the steps to verify the issuer is to “check if the issuer can be trusted” - this normally happens by simply providing the list of “trusted” domains but with “custom domains” in the twist this makes the list of domains twice as big… And also requires every micro-service that we have in place (currently about 5) to have a list of these domains maintained manually. This obviously is not ideal so we devised a way to validate the issuer by the means of “signing” the issuer claim at a trusted party (Auth0) with a private key and then verifying that signature in each micro-service using a public key. Unfortunately we’ve hit yet another problem - the “contexts” available in “Rules” as well as “Hooks” are different and although Rules expose “context.request.hostname” that we can use to validate the issuer field as it will be directly related to “iss” claim, in Hooks however - the only thing we can use is the “context.webtask.body.client.tenant” which doesn’t have to directly relate to “iss” claim found in the token… In fact the “iss” claim is always set to the “domain” used to request the token which makes sense but inability to access either the “issuer”, or domain in both contexts is somehow annoying… Has someone come up with a way to “verify” the “iss” claim without the hardcoded list?
Q3: Why does the “iss” contain a trailing slash?
I think it would make sense for Auth0 to expose the “issuer” field in both contexts just as they will appear in the token to begin with as well as the “custom” or “original” domain the request belongs to… Can we hope for that Auth0?
Hi Krysztof.
Hooks are not supported in the Github deployment extension because of another missing feature: API support for managing hooks. While this is recognized as something that needs to be address, it’s not yet there because of other product priorities.
I’d recommend voicing this (and the requirement of accessing the domain name used in the request) in Auth0: Secure access for everyone. But not just anyone. as the best way to reach the Product team.
As for the trailing slash, it’s just a design choice of using a URI with the root path of the domain.
In the case of you microservices, would it make sense for you to centralize the list of valid issuers in one place (like a database or URL resource) and have the microservice read and remember that list upon startup?
Another option would be to validate the tokens at the edge/gateway, and from there on talk to the microservices using a M2M token (from just one issuer). But I’m throwing these recommendations blindly without know your exact architecture, how your clients make requests to different tenant backends and so on, so apologies in advance if none of this applies to your case, or if they are obvious solutions that you’ve already considered.