Group claims are not in the jwt token
wvdd007 opened this issue · 13 comments
Hello. I was able to run this demo in no time thanks to the walkthrough. Is there something special being done with "group" claims for these kinds of applications ? For the same user and the application "webapp-groupclaims-dotnet" (another of your samples), I do get the group claim in the principal; while here I don't seem to receive it. Do you have any idea of what I am doing wrong ? (I altered the manifest files of bot the api and the app to have
"groupMembershipClaims": "All".)
Hi @wvdd007.... Yes, there's some unique behavior around group claims in the SPA scenario. Group claims can quickly inflate the token, which in this case is returned in the fragement of the URL. Some browsers have URL length limits, so returning group claims in the token is not reasonable. Instead, you should query the Graph API to get the user's group membership.
I was aware of that but I thought WAAD had a policy for that (max 200 claims in jWT token, max 150 in SAML2 with an overflow claim both cases).
However, the behavior I have is that for one application the group claims are in the token while for another they are not. On the azure side there is no difference in configuration for both so I would say that the server should expose the same behavior for both.
Unless somehow you call the server with different parameters ?
Are both of those applications single page apps?
Regardless, we do have a bug open right now on this topic. It affects architectures where a single web API accepts access tokens from both SPA's and other types of clients, and expects group claims (or the overage claim) to exist in the token. Is that what you're trying to accomplish?
No, they are not both SPA's. But they use the same WAAD so I expect the same security tokens. I thought that the server provides the same tokens to each RP, regardless of what client type it is. That way scenario's like the one you talk about become possible : An App or a website or whatever gets a token and passes it to the API. Unless otherwise configured I expected these tokens to be the same.
Now I have one SPA and one other application using ADAL. The SPA app doesn't get security groups while the other does get them. I am just wondering where that difference comes from.
I think we're on the same page here.. . The difference comes from a bug we currently have. We're trying to work out the best way to support apps that depend on the existing behavior while updating to be in line with what you describe.
Hi, so what is the recommended approach to secure and authorize Nodejs REST endpoints for a SPA? Does the passport-azure-adal in combination with the ADAL for JavaScript not enough to secure JavaScript rest endpoints based in AAD groups?
Team, I have the same problem, Do you have any update on this topic? I need the Group Claim in The Id_token
I'd also be interested in the solution. Diverging from the original issue a bit but I tried calling the getMemberGroups API on the backend side (as on-behalf-of flow) but that's returning "Authorization_RequestDenied .. Insufficient privileges". From documentation I understood that User.ReadBasic.All and Group.Read.All permissions would be enough for those but even then it fails. The token contains those: "scp": "Group.Read.All User.Read User.ReadBasic.All"
Could we get groups or role of a single user from Angular Token? I have turn on "groupMembershipClaims": "All" but does not seem to work. No groups or role in token.
It looks like the group claim limit is 5 groups. If your user is in 5 groups or more, the group attribute won't be send in the id_token
Hi Everyone,
I have a question about this. We have 2 App Registration in Azure in this example: ToDoApp and ToDoApi
When we assign roles or groups claims to users in ToDoApp. Do we need to apply the same things to ToDoApi? If yes then we have to manage roles/groups twice in 2 apps.
Is there any way in ToDoApi we authorize Roles/Groups of users based on ToDoApp not ToDoAPI?
Thanks
What I learnt recently is that groupMembershipClaims values are only present in the id_token, not in the access token. Which means that if I want my WebAPI layer (the 'lowest layer' public interface) to perform checks for a given caller is part of an AD security group, then it is not possible.
Closing this as we are archiving this sample. Please check out the new sample at ms-identity-javascript-angular-spa-aspnetcore-webapi.