Most web apps do not need a full role-based access control system. They need a gate at the front door that says "only people in this group get a token". Building RBAC for that is over-engineering, and the maintenance cost shows up later.
Azure AD has a one-toggle answer. Flip "User Assignment Required" on for the Enterprise Application, assign a group, and the app silently refuses tokens to anyone outside it.
Setting up the restriction
In the Azure Portal, open Azure Active Directory, then Enterprise Applications, and pick the registration tied to your app. Under Properties, switch User Assignment Required to Yes.
Before the flip, any user in the directory could request a token for the app. After the flip, the app returns an error that the signed-in user is not assigned to a role for the application. Same behaviour whether the app is ASP.NET Core 2.1, Java, Node, or anything else that hits the Azure AD token URL.
Now assign users. Under Users and groups for the same Enterprise Application, add the people or groups that should have access. Adding a group grants every member access; adding a user grants just that user. If you run separate app registrations per environment (a sensible habit), repeat the assignment for each registration. The configuration does not sync across them.
Why this works without writing code
The assignment check happens before token issuance. Your app does not need custom authorisation logic to enforce membership. It just sees the token arrive for allowed users and fail for everyone else. This is ideal for the common case where the application itself has no concept of roles and just wants a closed user group.
For MSI service principals, the picture is messier. Adding the MSI to an Azure AD group does not satisfy the assignment check; token requests fail with a not-assigned error. The workaround is to define a dummy application role on the app registration and grant that role to the MSI. This keeps automation flows alive while still gating human users.
Our analysis
For small-to-medium internal apps, group restriction hits the sweet spot between friction and effort. It is faster to configure than conditional access policies, easier to audit than scattered app roles, and it does not require code changes for the common "members of this team see this dashboard" scenario.
The MSI caveat is the real trap. Anyone building pipelines or automation that logs in as a service principal will hit a wall, and the wall is not obvious from the portal UI. The group appears configured correctly, but the token request still fails. The dummy-role workaround solves it, but it means two configuration steps instead of one. Plan for this upfront if your app runs background jobs under MSI.
There is a subtle gap to know: group membership changes in Azure AD propagate quickly, but token caching on the client side can mean a recently removed user still has access until their token expires. Short token lifetimes plus a forced sign-out on rejection close most of that window.
Who should care
| Scenario | Use group restriction? | Watch out for |
|---|---|---|
| Internal dashboard with no roles | Yes | — |
| Multi-tenant SaaS app | No | Assignment applies per tenant |
| App with MSI background jobs | Yes, with dummy role | Group alone will not work |
| App shared across org boundaries | Check with security team | May need conditional access instead |
Worked example: locking a reporting dashboard
Say you have a reporting dashboard used only by the Finance team. The app is already registered in Azure AD.
- In Enterprise Applications, find the dashboard's app registration.
- Under Properties, set User Assignment Required to Yes and save.
- Under Users and groups, add the "Finance" Azure AD group.
- Tell the team to sign out and back in; their next token request will succeed.
- Anyone outside Finance now gets an error when the app calls the token endpoint.
If the dashboard has a nightly MSI-driven export job, do not stop at the group. Add a dummy application role on the registration, grant that role to the MSI service principal, and the export keeps running while the human gate stays closed.
What to watch next
Audit your existing Enterprise Applications. Anything marked User Assignment Required = No is open to every user in the directory, which is rarely what teams actually want. Roll the toggle to Yes for any internal app that should not be world-readable inside the tenant. Keep an eye on Azure AD release notes too, since the assignment model gets tighter with each iteration.
Key takeaways
- Turn on User Assignment Required for any internal app that should not be directory-wide.
- Assign a group, not individual users, when more than a handful of people need access.
- Repeat the assignment per environment registration.
- Use a dummy app role for MSI service principals, since group membership does not satisfy the check.
Frequently asked questions
Does this require code changes in my app?
No. The check happens at the Azure AD token endpoint, so the app just sees allowed tokens succeed and others fail.
Can I assign an Azure AD group instead of individual users?
Yes. Adding a group grants access to every current and future member.
What about MSI service principals?
Group membership does not satisfy the assignment. Define a dummy application role and grant it to the MSI instead.
Do removed group members lose access immediately?
Usually yes, but client-side token caching can delay the effect until tokens expire or users sign out.