Feature Request: Option to use the id_token instead of access_token

[MarkJaroski]

trafficstars

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?

[davidjrh]

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. Check the B2C provider here: https://github.com/intelequia/dnn.azureadb2cprovider

[MarkJaroski]

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!

[MarkJaroski]

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.

[davidjrh]

By using the OpenID Connect provider. Check these docs:

• Using user flows (single tenant): https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant
• Using B2C custom policies:
  • Single tenant (single tenant): https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant-custom
  • Multi tenant (multi tenant - B2B): https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-multi-tenant-custom

[brbeaird]

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. I made a quick pass at modifying this to work with id_token; it does, but it's currently too messy to submit.