Is there a way to access multiple claims when using custom authentication?

[TellonUK]

I am using Azure B2C as my identity provider and it returns the name by default (firstname givename). I can access the user's email address if I use the below configuration, but I then no longer have the users name.

"nameClaimType": "emails",

Is there a way to request multiple claims from the decoded token? In my situation name and emails ?

[mkarmark]

There currently is not a way to do that. In what form would you want multiple claims presented to you? Would a comma separated list make sense here?

[TellonUK]

I think that makes sense. Adding something like the below to the config, and then receiving a response in the same order.

staticwebapp.config.json:

optionalClaims : [ 'name', 'emails', 'etc']'

Additional to clientPrincipal response:

optionalClaims : [ 'firstname givenname', 'xyz@abc.com', '...']'

If a claims is requested that isn't in the jwt response, then the same as you have setup scopes would be ideal, a simple 500 error.

[GaryParr]

OK, so... perhaps I'm missing something but why can't we have access to the whole blasted B2C claim? I understand SWA needs a single value to map into their existing clientPrincipal.userDetails property... but what's wrong with adding a clientPrincipal.providerClaim field that contains everything? This would assist with other efforts as well, such as #415

[mrfoster]

I think this is absolutely necessary and was surprised to find that I wasn't able to get at them. I'm sure there are many many reasons to do so, but I am storing the plan the user has subscribed to in a claim and want to be able to retrieve it..

[alefranz]

Hello! I'm currently looking to migrate a website from AppService to Static Web Apps and I am blocked by this.
I think the ability to override the json object passed as claims parameter would be enough to start with, as well as then adding these to the client principal data.

[anthonychu]

@alefranz We're working on some improvements in this area. Can you describe a bit more about what you want to do?

[alefranz]

@alefranz We're working on some improvements in this area. Can you describe a bit more about what you want to do?

Hi @anthonychu , the OIDC provider I am using allow me to provide multiple claims so to be able to request for more user info from the UserInfo endpoint e.g. profile picture. Currently I am using the ASP.NET Core OpenIdConnect library and I override the OnRedirectToIdentityProvider to replace the claims parameter with the JSON with the list of claims I need. It is not the most elegant solution but allows me to achieve this, so it would be nice to have a similar solution here as well. Let me know if you need more details.

[anthonychu]

We released a feature to programmatically assign roles with a function. Within the function, you have access to the token from the IdP as well as the claims. See the documentation for more details. There's also a tutorial with a sample app.

Currently you can use this function to assign roles. You can access these claims in the role assignment function and save them in a database for access later. If you'd like to also store claims that you can access in the /.auth/me endpoint or in the user principal in a function app, let us know.

[Skleni]

@anthonychu Thank you for implementing this! It definitely makes some scenarios easier. We could still use a possibility to store claims as you suggested though, for scenarios where the claims in the identity provider's access token contain information that can't directly be mapped to roles. Some examples would be the user's tenant/company/department...anything that might be relevant for access control.

Using the new role function, we can now access this information during login, which is of course better than not at all. But as you said, we still have to store it in a database and look it up on every request, which could be prevented if it could be added to the SWA's principal.

[GaryParr]

I'll second the request for storing claims in the /.auth/me endpoint and the user principal. Though, to be clear, are we talking about just the IdP claims or are we talking custom claims defined in the function that's assigning roles?

[anthonychu]

@GaryParr it would be whatever that function decide to store as claims. There’d likely be some limits for size.

[anthonychu]

@miwebst Can you see if it’s possible to support this?

[alefranz]

@anthonychu I second the request to get access to the claims. For my scenario I would also need the ability to provide a list of claims to include in the request.

[danwatford]

I raised a related issue against the documentation as a I didn't realise this repository existed for reporting problems - https://github.com/MicrosoftDocs/azure-docs/issues/86803

Per the linked issue, claims are now available at the /.auth/me endpoint, which is good, but documentation suggests they should also be available to functions via the x-ms-client-principal header.

@anthonychu , do you know if claims likely to be included in the x-ms-client-principal header in the future?

[gordonk]

Per the linked issue, claims are now available at the /.auth/me endpoint, which is good, but documentation suggests they should also be available to functions via the x-ms-client-principal header.

@anthonychu , do you know if claims likely to be included in the x-ms-client-principal header in the future?

Yes thanks for all your hard work, but like Dan above I have not seen claims passed in the x-ms-client-principal header even thought the documentation clearly states they are.

[LuKePicci]

The doc is now saying the truth, they're not passed to functions. However, as @Skleni said, it is possible to store claims at login time as roles. For instance, you can grab tenant id and return a role like "member of-{tid}".