Hello,
First time asking things here, but in simple terms I am trying to federate entraid governed accounts to go and sign themselves up and get scopes and then return to b2c user journey and send tokens to associated app with custom policy. I use Oauth technical profile to do this, since I want access_token and refresh_token from this federation (somehwere in github I believe Jas Suri mentioned you cannot have refresh_token if using OIDC, but need to use Oauth instead in the technical profile). My technical profile should mimic this links instructions:
https://github.com/azure-ad-b2c/samples/blob/master/policies/B2C-Token-Includes-AzureAD-BearerToken/Readme.md
Outputclaims and transformations are additions from other examples for writing user info to tenant. And scope input is me asking for some scopes that are included in the technical profiles scope collection.
And the problem; If I request the openid offline_access and the User.read scopes as in the link's example, I get access_token and refresh_token. If I ask for azure storage user_impersonation alongside the openid and offline_access scope, "I get error AADB2C90289: We encountered an error connecting to the identity provider. Please try again later." when redirecting to jwt.ms after user journey completes via send claims. Interestingly still, EntraId shows in signin logs that I did request for storage related scope, because the resource and its id are populated correctly along with the home tenant id and the resource tenant id. To make this more confusing, the logs say pretty much the same story when requesting graph resource scope. Furthermore, When accessing app with a user account for the first time, scopes are properly asked for consent. When debugging with chrome dev tools, networking shows that auth code is being returned and authresp endpoint is getting redirection after successful sign in and input to initiate sign is reflecting the scopes I'm requesting.
Some things I did check, because I'm pretty much out of ideas, most of these I didnt even think would help;
- Checked client secret is correct
- Checked client_id to be the app that signs in users for federation
- Separated scope with something else than space (though I believe space should be the delimiter. When using comma, I got error for invalid scope, which seems reasonable)
- Used different urls of authorise and token endpoints (ending with .srf, example in github I believe by Jas Suri)
- Changed acceptmappedclaims to true (in federation app and in client using the custom flow)
- Gave admin consent to all permissions (even though the app asked consent for all the permissions when initially accessing it, did this anyway. )
- And of course everytime to ensure no cache magic is happening in the policies, I uploaded a new policy instead of overriding old ones and ran the run now endpoint in incognito mode.
Any hints forward appreciated. Thanks a thousand in advance.