Application assignment now gates sign-in, and the new launcher
An app with zero assignment rows still opens to everyone — that's what keeps every already-configured app working. The moment it has one row, only an ACTIVE assignment passes, for SAML, OIDC and SWA alike. Plus the new /my-apps launcher.
The gating rule
An application is gated the moment it has at least one assignment row of any kind, from any status. Before that point — an app configured with no assignments at all — sign-in stays open to everyone, exactly as it always has. This is deliberate: it is what keeps every application you configured before this change working without you having to go back and assign it to anyone.
Once an app has one assignment row, the rule flips: only an ACTIVE assignment — either directly to the signing-in person, or to a group they belong to — lets them through. Everyone else is refused, whatever their role otherwise is. This is checked at each of the three sign-in surfaces:
| Surface | Refusal |
|---|---|
| SAML | 403 before the assertion template is even resolved, {"error":..., "code":"iam.app_not_assigned"}. |
| OIDC | Checked when the authorization code is issued (/authorize answers access_denied, description iam.app_not_assigned) and again when tokens are issued — so removing an assignment stops a refresh from working, not just a fresh sign-in. |
| SWA (password fill-in) | 403 with the code, before anything is decrypted — see Apps without SSO support. |
A gate read failure — the assignment lookup itself failing, not a lack of assignment — refuses as a server outage rather than as a 403, so an infrastructure problem never reads to a user as "you don't have access."
Because of this, the Status field on an assignment now genuinely matters, correcting what App assignments currently says about it being inert: Inactive really does mean nobody gets in through that row any more, once the app has crossed into being gated.
Hiding an assignment from the launcher
An assignment can now be flagged hide_from_launcher. This does not change sign-in access at all — it only controls whether the app's tile shows up on the end-user launcher described below. Use it for an app somebody is entitled to but that shouldn't clutter their tile list — an administrative tool they use rarely, say.
The new end-user launcher at /my-apps
There is now a real, assignment-aware launcher: tiles for every app you're actively assigned to (directly or through a group, hide_from_launcher respected, ACTIVE only), a recently-used row, and search. It records each launch for that recently-used ordering.
For an SWA application, the launcher tile currently opens the application's own sign-in page rather than automatically filling the credential — the actual credential fill still happens at SWA's own launch endpoint, which independently re-checks the same assignment gate. The launcher is a directory entry pointing at it, not a bypass of it.
What to do about this now
- Before you assign anyone to an app for the first time, understand you're about to gate it for everyone else. The instant an app gets its first assignment row, everybody without one loses access — including people who were signing in fine a minute before.
- If you were using assignments purely as a paperwork record for an access review — the use case App assignments describes — check now whether any of those apps have crossed into being gated, and confirm the people you expect to have access actually hold an ACTIVE row or ACTIVE group membership.
- Use
hide_from_launcherfor entitlements you don't want cluttering the tile list, not as a way to restrict access — it does nothing to sign-in. - Point people at
/my-appsfor the new tile-based launcher rather than any bookmark to the old unfiltered list.