Return social IdP's native access tokens back to the app
Return social IdP's native access tokens (for e.g., Facebook access tokens) back to the app.
Azure AD B2C now allows the access tokens of OAuth 2.0 identity providers to be passed as a claim in the B2C token. Please try it out (see instructions below) and give us feedback at firstname.lastname@example.org.
User flows (built-in policies)
tested it with public policies and it works like a charm :-) thanks
Hi all - in the meantime please follow Antons guide https://github.com/Dayzure/aadb2c-ief-facebooktoken to retrieve the IdPs native access token via B2C custom policy.
Jeremy Whiteley commented
This is must have feature! Please give us the ability to access Facebook info.
I previously had my application directly connected to Facebook. With this setup I was able to get all the information about the user: gender, profile picture, link to profile, locale, etc. I like this because I can directly re-use this information in my app and my users don't need to go through yet another sign-up process to re-enter the same information which is too high barrier to entry and might make them leave.
However, I wanted to use facebook tokens to call my web api but from my understanding this is not possible to do safely. It seems Facebook doesn't return JWT's. Their tokens are essentially opaque except for the special /debug endpoint but that can't be used for validation since it requires admin access token to request. From my understanding this means facebook tokens can only be validated by facebook not on my web api. This made me look to B2C as a solution to give me Facebook login but a predictable way to validate tokens issued by AAD.
This worked very well, but now I only get the email and name of the user and lost the ability to show their nice picture which they would mentally associate with their profile.
There was similar question in the FAQs about this:
"Can I configure scopes to gather more information about consumers from various social identity providers?
No, but this feature is on our roadmap. The default scopes used for our supported set of social identity providers are:"
I originally though exposing more claims might be difficult since you would likely want to standardize across all Identity providers, but then I thought there could be alternative solution of exposing the token the identity provider returned as another query parameter in the authentication response. Today we get access_token, id_token, and maybe we could get idp_token or original_token. I could then use this facebook token to manually request the users photo or whatever I wanted. This way it's up to the developer to diverge and do the custom logic but they get the best of both worlds. They get the awesome management and normalization B2C provides but they also have the ability to go get data directly from the identity provider if they choose to.