Skip to content
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

Closed
theFroh opened this issue Mar 14, 2018 · 9 comments
Closed

How to handle multiple issuers #84

theFroh opened this issue Mar 14, 2018 · 9 comments

Comments

@theFroh
Copy link

theFroh commented Mar 14, 2018

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's iss. 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 in authorizationCallback (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).

@panva
Copy link
Owner

panva commented Mar 14, 2018

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.

@telemmaite
Copy link

I had similar problem. In the end I really needed to have a single central place to handle authentication.
But depending on the user email domain, you could get redirected to different IDP provider, from the main node-oidc-provider. So it integrated nicely with Azure IDP where I had to register as a callback only the Azure AD client used by node-oidc-provider which talks together as Service to service.

Flow is :

  1. Type email inside started /interaction/uuid session of node-oidc-provider
  2. Check the domain of this email - for certain domain redirect to /login in passport-azure-ad route save session information that it is node-oidc-provider request
  3. Once the user completes authentication on Azure IDP the callback url points to /done inside passport-azure-ad
  4. At this point passport-azure-ad validates whatever it is provided to the callback and creates a simple JWT token with information if the sign in was successfull then this token gets send as Service to Service back to node-oidc-provider interaction route which makes validation and if OK calls oidc.interactionFinished at this point I make a proxy user with claims coming from custom JWT.

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 node-oidc-provider client you dont need any extra setup to login with Azure, it is handled on the node-oidc-provider space.

@panva
Copy link
Owner

panva commented Mar 14, 2018

@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.

@theFroh
Copy link
Author

theFroh commented Mar 14, 2018

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 theFroh closed this as completed Mar 14, 2018
@G1itcher
Copy link

G1itcher commented Dec 6, 2018

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's iss. 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 in authorizationCallback (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).

@theFroh
Yes please on the Types, otherwise I'll have to make my own!

@ulrikstrid
Copy link

Opened a PR that solves this #148

@tetchel
Copy link
Contributor

tetchel commented Feb 21, 2019

Hey @theFroh @G1itcher I'm also looking for typescript definitions for this library. If you want help putting together a PR for DefinitelyTyped I'd be willing to help out.

@panva Could we create a separate issue for creating TypeScript definitions for this package, if you have any interest?

@panva
Copy link
Owner

panva commented Feb 21, 2019

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.

@panva
Copy link
Owner

panva commented Mar 6, 2019

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.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants