-
Notifications
You must be signed in to change notification settings - Fork 21
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
Feature Request: Option to use the id_token instead of access_token #28
Comments
Have you played with Azure AD B2C? It covers internal and B2B scenarios, and you can fully customize (with a bit of experience) the user flows, user attributes, claims, etc. |
Thanks David. We did give it a try. I didn't realise that it also covers internal and B2B users. I'll go give the documentation a more in-depth read. Thanks! |
How do we configure the B2C provider to use B2B and internal users instead? We don't have a B2C tenant, so the first part of the handshake fails. |
By using the OpenID Connect provider. Check these docs:
|
I would still love to be able to use id_token to map a property to userId. I tried the B2C route, but it's way overkill for our case. Our existing DNN users are all set up with EmployeeID, not e-mail address. While you can add EmployeeID as a mapped claim, it only appears in the id_token, not access_token. |
We're running into some limitations in our implementation which has to support B2B (Azure Guest) users and internal users.
I'm considering changing things around a bit to use the id_token rather than the access_token for incoming claims, since we have a bit more flexibility with configuring the claims present there.
What do you think about the idea?
The text was updated successfully, but these errors were encountered: