Tenant sign-in inside your own interface

Imagine an appointment portal for a small practice. A member opens the portal, signs in beside its familiar branding, and returns to the calendar. On a shared browser, an account selector makes it clear whose appointments are on screen.

That is a useful reason to build your own sign-in interface. M7's tenant browser-direct contract lets an organization-owned application present its own forms and call SSO from the browser. The organization still owns the member and controls admission. Consumer accounts cannot use this tenant flow directly; a tenant member signing in through a consumer link remains a tenant member.

Hosted sign-in is another integration choice, with its own full-page, popup and iframe presentations. This article follows the app-owned journey.

Set up the boundaries first

Follow the browser-direct setup guide: use an eligible, active organization-owned app and register its exact HTTPS callbacks. Their origins determine which browser requests are admitted; there is no wildcard origin allowance. Enable the capabilities you intend to offer. Browser-direct authentication, signup and email sign-in each default off, with organization and application policy controlling them. Registration and federation have additional gates.

Build the screen from reviewed app configuration: there is no public policy/provider discovery endpoint to populate it for you.

The browser holds its own signing key and uses mandatory DPoP proofs to bind requests to that key, alongside PKCE and callback-state checks. It sends no client secret and does not use hosted SSO cookies. Ordinary confidential OAuth credentials are not browser-direct credentials. Your integration must also confirm token activation before treating a pending token as usable.

Follow one member through the door

In our illustrative portal, Maya can enter her tenant username or an unambiguous verified email and password. If the app allows federation, it could also show a configured GitHub button. Provider sign-in still navigates through a popup or full page; your own interface does not embed the provider's password form. Applicable tenant password sign-in may require a second-factor step.

Give new members a separate Create account action. The signup and recovery guide describes a draft, email confirmation where required, and explicit completion. Proving a provider account does not create a member, and an unsuccessful provider login does not silently create or link one by matching email.

After completed signup, the portal offers sign-in, or explains that approval is required. Signup itself grants no access token. A genuinely unfinished native signup may resume from sign-in; an arbitrary disabled account cannot use that route to reactivate itself.

If Maya forgets a native tenant password, recovery can verify her usable, verified email and let her set a replacement. She then signs in afresh. That recovery action does not reset a provider's password or consumer credentials, and it does not remove her tenant second-factor enrollment.

Make the selected account visible

The portal can remember up to 16 members in a container bound to this app, browser origin and signing key. Show the selected member clearly, particularly before an action such as changing an appointment.

Switching to another remembered member checks current access policy. It is not fresh sign-in. A pending switch becomes selected only after token activation succeeds; a denied switch leaves the previous selection intact. Keep the screen consistent with the confirmed selection.

The session guide gives logout the same clarity. Removing the current account leaves no selected replacement: let the person choose or sign in explicitly. Log out all closes this app's current browser container. It does not sign everyone out across other devices, applications or hosted SSO sessions.

A coherent interface makes each transition understandable: create an account, finish verification, sign in, choose a remembered member, or leave. Those explicit choices help people keep track of whose account they are using, while current tenant policy continues to decide access.