-
-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle multiple issuers #84
Comments
Hi @theFroh, the glaringly obvious thing to do is also a best practice and a requirement for some OIDC profiles. Use unique callback routes for each issuer and even their clients should you have more for each. Or push the issuer and client identifiers in your session / bind them to your provided state parameter and only use that one during callback. |
I had similar problem. In the end I really needed to have a single central place to handle authentication. Flow is :
In the end I have for example: 5x clients/apps calling -> 1x node oidc provider (5x client app registrations) -> 1x passport azure app -> 1x Azure IDP (1x client registration). So as long you are |
@telemmaite the two libraries aren't linked, it's great that you understood how to use them together but in @theFroh's case, its likely just having multiple IdPs and having to distinguish them on the way out. What you're describing also does not eliminate the possibility to implement the best practice for unique callback uris, as it doesn't matter where the call was started from, only the registered callback uri. |
Ah cheers, that's was my other option; separate callback endpoints. In this case I'm playing around with giving administrators the ability to add support for arbitrary IdP's; I'll just have to dynamically add callback endpoints as needed. |
@theFroh |
Opened a PR that solves this #148 |
I'm happy to review them, but maintaining them i can't promise, that's an overhead i don't have the capacity for atm. Plus it may be worth it for you to wait for v3.x, plenty of changes in that API. |
Change of heart, i'll bundle definitions with 3.x and I welcome you to validate them once out. I'm a typescript novice so i don't know if what i'm doing is "standard", that being said i tried to use the types and it worked for me. It would be immensely helpful if you could check this issue so that i can maybe avoid the same problems that may be there. |
Apologies for putting what is effectively just a user question into the issue tracker!
I've been having some trouble working out the best way to handle multiple issuers, particularly during callback handling.
Looking at how a Client is tied closely to its parent Issuer, one method I considered was simply maintaining a list of acceptable Issuers, and iterating through them upon callback until validation passes (if it passes). Having a squiz at what I could expect data-wise coming with the callback, however, I'd have thought a better option would be to instead only use Issuer that matches the callback
sub
claim'siss
. The issue I have with this is that I can't find a way to simply decode the callback to retrieve this claim without also failing inauthorizationCallback
(as I must use a Client and Issuer that probably isn't the correct one).The entire callback body would be decoded and validated by a client of the "correct" Issuer after identifying which Issuer to use.
Is there anything glaringly obvious that I'm thinking about, or doing, incorrectly here?
Cheers for the great library!
P.S. while poking with this, I've put together a basic Typescript definition .d.ts that you may be interested in (lest it may later find its way onto DefinitelyTyped).
The text was updated successfully, but these errors were encountered: