Checking Azure Active Directory group membership via MSAL in a SPA + Web APIs

Question

I am building an application which has a front-end (a SPA built with Vue.js) which interfaces to a couple json-based Web APIs in the back end (hosted in Azure). The Web APIs need to be secured via Azure Active Directory and users must be a member of a security group. Furthermore, the SPA should simply try to force the user to sign into an approved account if they are not signed in as one (i.e. just auto-redirect).

I actually have all this working. The AAD application has Group.Read.All, the user signs in via the SPA and gives consent, and the SPA calls getMemberGroups. Furthermore, the Web APIs can check the SPA-provided access token, and the Web APIs unfortunately must also call getMemberGroups.

And I think that is my concern. The Web APIs keep having to call getMemberGroups to lock it down. If I did the auth on the service, I could potentially only return an access token once membership groups has been verified. But then I lose the easy MSAL sign-in model in the SPA - the Web APIs don't actually provide any front end, the SPA is statically hosted.

As far as I can tell, I cannot get Azure Active Directory to create a token guaranteed to have certain group claims in it. I think this would solve my problem.

Can somebody offer some advice on the best way to design an auth model around a SPA + Web API environment? Or is the method I have taken the only way to do it?

Thanks!

Mucor

Answer 1

You can include Groups claim in your token as instructed here. You just need to modify the "groupMembershipClaims" field in application manifest:

"groupMembershipClaims": "SecurityGroup"

Then the token will contain the Ids of the groups that the use belongs to like below :

{
  "groups": ["1ce9c55a-9826-4e32-871c-a8488144bb32"]
}

You can also leverage Role along with Groups to control access of your application. You can define some applciation roles and assign the roles to the groups. Then the users in the group will have the claim like below:

{
  "roles": ["admin"]
}

Then you can implement your authorization logic based on the roles of the user.

Refer to https://joonasw.net/view/using-groups-vs-using-app-roles-in-azure-ad-apps and https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps for more details

Mclaughlin

Thanks. Those links are exactly what I needed. The groups solution doesn't seem polished because it makes the token too big, and can overflow and I have to make the call anyway. But the app roles solution was perfect. The only downside is I couldn't test app roles in my free tenant, but its not too expensive to worry about, and after testing was done I could just mock it moving forward. I have this working with roles e2e now, thanks! – Mucor

@Mucor Glad it's helpful :) – Mclaughlin

Really useful links, definitely considering role based instead now. While this works on the frontend SPA really well. I do not see Groups or Roles in the claims sent to my Web API, can this strategy be used to lock down the Web API to the Group/Role as OP mentioned? – Personalty