SSO Groups Give Hosted Apps a Front Door

An account is not the same thing as access.

That sounds obvious until a product has more than one offering. A customer can have an account with an organization and still be entitled to only one publication, one catalog, one partner portal, or one service tier. The identity system has to recognize the account without turning that recognition into a blanket pass to everything the organization runs.

M7 hosted SSO now has that control: an OAuth application can use organization-scoped groups as its front door.

The shape is intentionally small. An OAuth application can name groups for registration, groups for login, or both. The application receives the same tenant identity model as before; the new configuration decides whether a tenant member should be enrolled when they are created and whether that member is currently allowed through the application's sign-in path.

One organization, distinct offerings

Take Stanley's Sprockets.

It may operate Sprockets Illustrated for subscribers and Sprocket Catalog for wholesale buyers. Those are separate offerings, but they do not need separate identity silos. They can use the same organization, keep tenant members in that organization, and put each member in the group that represents the access they bought or the relationship they hold.

The Sprockets Illustrated OAuth application can admit members of illustrated-subscribers. The Sprocket Catalog application can admit members of wholesale-catalog. A person in both groups can use both products. A person in only one cannot accidentally use the other just because the organization recognizes their account.

That is the distinction worth preserving: tenants remain organization-scoped, while application issuance is group-scoped.

Registration and login are different jobs

The configuration has two independent options.

register groups are automatic enrollment. When a new tenant password account is created for an application, M7 adds that tenant member to every active group named in the application's registration configuration. The write is idempotent, so retried signup requests do not create duplicate memberships. If the memberships cannot be established, signup does not report a partial success.

login groups are admission. A tenant member needs an active membership in at least one configured login group to proceed. This is an any-of rule: an application can offer several valid routes in, such as a paid subscriber group or an internal staff group, without requiring a person to belong to all of them.

An application can use either option alone. A public app might enroll new people in readers but allow multiple groups to sign in later. A closed wholesale app might skip automatic enrollment entirely and admit only members placed in its group by an operator or an upstream process.

Federation is a hybrid path

Password signup and password login are cleanly separate operations. Federation is not.

The first federated visit may create a tenant member and needs the registration enrollment before it can finish. A returning federated member needs the login admission check, just like a password member. M7 handles both cases as one sequence: resolve or create the tenant member, apply any effective registration groups, then test the live login policy before it creates the usable sign-in result.

The important part is that federation does not become a loophole around the same admission rule. Provider proof establishes who the person is; group membership establishes whether that tenant member may use this application.

The check follows the session

An access rule only matters if it runs at the paths that can issue access.

M7 applies the login-group rule after password proof and before it stores a browser session or returns an authorization code. That order is deliberate. A bad password receives the ordinary invalid-credentials result rather than revealing whether the named tenant member belongs to an application's allowed group.

The same recheck happens when a remembered account is selected, when an already-signed-in browser resumes an authorization request, and when a federated login completes. Selecting a remembered account is not an entitlement bypass.

Refresh tokens are also rechecked before they can rotate or produce a new access token. Removing a member from an application's allowed group therefore prevents the next refresh from extending their access. An access token already issued remains valid until its normal expiry; it is not retroactively rewritten in flight.

Active groups are the policy

The application configuration is not a bag of permanent identifiers. M7 resolves it against the tenant's active, unarchived, unexpired groups at the time it is used. A group that has been retired, expired, or otherwise gone inactive stops contributing to registration and login policy.

Membership has the same active-state requirement. A historical or disabled group-client relationship is not enough to enter an application.

This keeps routine access operations straightforward. Add a member to the correct active group and they can use the offering. Remove or deactivate that membership and the next protected issuance path stops. Retire a group and it stops acting as an application's accidental access rule.

A small option with a useful boundary

The new SSO groups option is not a substitute for tenant boundaries. Organizations still define the member pool, ownership, and administration boundary. Group policy gives each OAuth application a narrower, live admission rule within that organization.

That lets one organization serve several real products without turning every account into a universal key.

The front door is now configurable.