One hosted sign-in, several presentations

Someone is halfway through writing a comment when the app asks them to sign in. A whole-page journey may be perfectly reasonable. A popup may keep their work in view. An embedded sign-in panel may fit the page better still.

For an app builder, the useful question is which presentation fits that moment—and whether the person has a dependable route through it.

M7 Identity’s hosted sign-in guide describes full-page, popup and embedded presentations around the same underlying Web/PHP authorization and callback handling. The compatible Web/PHP 0.1.5 archive and separate M7 Identity Active Tags 0.1.1 archive are publicly downloadable.

Choose around the person’s task

Full-page sign-in takes the current window to the hosted sign-in page and returns through the registered callback. It is a straightforward starting point when leaving the current page is acceptable.

A popup keeps the original page visible while sign-in happens in another window. An embedded presentation puts the hosted sign-in page inside a panel on the app’s page. Both enhanced presentations use the base SDK and callback to complete the session. The application registration must permit the chosen presentation; embedding also needs permission for the exact app origin.

Imagine a small writing tool. Its builder could offer popup sign-in beside the comment editor, so the draft stays visible during authentication. The underlying sign-in link should still lead to a real full-page route. If the enhancement has not initialized or a required modal dependency is missing, that link continues to work as ordinary navigation. Preserving the unsent comment across that journey remains the writing tool’s responsibility.

Decide what happens after success

A sign-in frame loading is not proof that someone has signed in. The SDK validates the response and completes the callback before the session is treated as installed.

After that, the enhanced experience can reload the current page or close the modal, either automatically or after a click. Reloading refreshes session-dependent page content. Closing can suit an editor that needs to remain undisturbed, but the host app must update its own signed-in display. Automatic closing does not automatically fetch and paint the person’s profile.

For the writing tool, that choice matters as much as the popup itself: the person should see that sign-in worked and know they can continue.

Keep a route through browser limits

Embedded sign-in depends on the browser allowing the cookies and storage that maintain SSO state. Permission to display a frame cannot override those policies. If the browser cannot retain that state, use popup or full-page sign-in.

The documented popup startup checks can fall back to the full-page route when opening or initial navigation fails. They cannot recover an original page that the browser has unloaded. Test the complete journey in the browsers you support, including Safari, and keep the full-page route available.

These choices concern hosted OAuth/OIDC sign-in. Tenant-only browser-direct authentication has a different scope; it is not another presentation setting for this flow.

Start with a dependable journey, add the presentation that helps your app, and make the return to the person’s work clear.