Solution Patterns

When you decide to add consumer identity to your app, you face a small set of architectural choices. This page describes them at a generic level, so you can compare options before mapping them to specific product features.

Two Questions to Start

Most of the decisions on this page come down to two questions:

• Who shows the sign-in / sign-up screens, the identity product or the app?
• Who decides what comes next in the journey, the identity product or the app?

The four integration approaches in Part A answer these questions differently. Part B covers patterns that compose with whichever approach you pick.

Part A: Integration Approaches

The four approaches differ on UI rendering and journey control. Pick the one that fits your application's UX requirements first, then look at the supporting patterns in Part B.

Who shows the screens	Who drives the journey	Approach
Identity product	Identity product	Redirect-based
App	Identity product	App-native
App	App	Direct API

Redirect-Based

When a user wants to sign in, the app sends them to the identity product. The product shows the sign-in, sign-up, and recovery screens, then sends the user back signed in. Because the app never sees the user's password, this is the simplest security posture and the quickest path to a working sign-in.

The pattern covers sign-in, sign-up, recovery, additional-permission requests with consent screens, hosted-page branding, and signing the user out. It fits web apps, single-page apps, and mobile apps. The main trade-off is that the user has to leave the app for a hosted page. This can feel jarring inside a native mobile app or a heavily branded web experience, and UI customization is limited to what the hosted pages expose.

This pattern is typically built with a standard sign-in library or an SDK provided by the identity product. The underlying handshake is well-specified and not worth hand-rolling.

App-Native

The app renders every screen itself, but the journey lives on the identity product. This gives the app full control over what the user sees while keeping step ordering, branching, and policy on the server. The pattern is the best fit for native mobile and any "all in the app" experience.

The full set of journeys is covered with custom UI: sign-in, sign-up, recovery, profile changes that need re-verification, and invitation acceptance. The pattern handles multi-step prompts, multi-factor authentication, and steps that change based on the user or context. Branding is handled entirely in the app.

App-native has two flavors that trade UI granularity for app-side code:

• Step-by-step: the app sees every step the journey defines. After each step, it calls the identity product for the next step's details, renders the screen the server describes, captures the user's input, and posts it back.
• Managed: the identity product orchestrates the journey internally and only exposes outcomes to the app. The app says "the user wants to sign in" and reacts to whatever the product hands back. But the app decides how to render each screen and capture input.

This pattern is typically built using an SDK provided by the identity product. The SDK handles the per-step (step-by-step) or per-outcome (managed) calls and state so the app can focus on UI.

Direct API

Small, single-purpose API calls, for example "authenticate with username and password" or "send an OTP and verify it". The app strings these together itself, with no journey between the app and the primitive. This pattern fits two situations well. First, clients who want the simplest possible login with no application or flow configuration on the identity product side. Second, headless or scripted scenarios where a guided journey isn't useful, such as server-to-server authentication, internal tools, and automation.

Coverage is typically limited to the primitives the identity product exposes, often authentication only. Because there is no journey, journey-level policies (multi-factor, conditional steps) are not applied; the app is fully responsible for getting the identity logic right.

This pattern is built by calling the APIs directly; an SDK adds little here.

Part B: Supporting Patterns

These compose with any approach in Part A. They are independent decisions: a redirect-based app and an app-native app can use the same federation, user store, API protection, and integration setups.

Identity Federation

External identity providers, both social and enterprise, let users bring an identity they already have to your app, removing the need to manage a separate credential. Done well, federation creates one user record per real person regardless of how many sign-in methods they end up using. Most consumer apps adopt at least one social provider, and prosumer apps add enterprise OIDC or SAML.

Federation requires a few specific decisions. Should a user record be created the first time someone signs in via a provider (just-in-time provisioning), or only after an invitation? Should multiple federated identities link to one user, and what is the linking signal (verified email, explicit linking, or both)? Should signing out of your app sign the user out of the federated provider too? Should a user be routed to a specific provider automatically based on their email domain? Each of these is configurable independently.

Capabilities Involved

• Social sign-in via Google, GitHub, and other social providers.
• Enterprise sign-in via OpenID Connect or SAML.
• Just-in-time (JIT) provisioning: create the user the first time they sign in this way.
• Single logout (SLO): sign the user out of every place they're signed in.
• Account linking: connect multiple sign-in methods to a single user.
• Home-realm discovery: route the user to the right provider based on their email domain.

User Stores

Where consumer identities live affects everything else: sign-in performance, recovery options, federation behavior, and migration paths. Most consumer apps run a directly-managed user directory inside the identity product. Other options are no local record at all (relying entirely on federation), an existing directory you own (LDAP or a custom backing store), or a mix.

The choice often comes down to source of truth: who owns the canonical user record. If the identity product owns it, you get the most features and the simplest operational model. If an external system owns it, you get integration with existing data flows and a single source of truth across the business. The trade-off is less flexibility on the identity side. A mixed deployment lets you move identities between stores at your own pace. This is useful during migrations or when different user segments have different requirements.

Capabilities Involved

• Directly-managed user directory.
• Federated-only, no local user record kept.
• External user directory (LDAP, custom backing store).
• Mixed: some users local, some federated.

Protect APIs the App Calls

Sign-in is one half of identity; the other is protecting the APIs your app calls after sign-in. The identity product issues tokens during sign-in, and the same tokens carry the user's permissions to your APIs. The API does not have to know who the user is; it only needs to validate the token and check the permissions inside.

Validation typically happens at the API edge, in a gateway or middleware that verifies JWT signatures or calls the identity product's introspection endpoint. Permissions are expressed as scopes (what the app may do) and audiences (which API the token is valid for). Grouping related APIs into a resource server lets multiple endpoints share one set of permission rules instead of each endpoint enforcing them ad-hoc.

Capabilities Involved

• Issue an OAuth2 access token to the app on sign-in.
• Validate the token at the API edge via JWT signature verification or introspection.
• Scope-based authorization checks.
• Bind a token to a specific API via audience / resource indicator.
• Group related APIs into a resource server so they share permission rules.

Connect to Other Systems

Identity is not an isolated system; it belongs to the business. New sign-ups should land in your CRM; password resets should trigger security event logs; failed sign-ins should surface in your monitoring. The identity product is the natural place to emit these signals because it sees every identity event.

Integration typically goes in two directions. Outbound: the identity product emits events to subscribers via webhooks, message queues, or a built-in event bus. Events include sign-up, password change, MFA enrollment, and federated link, so other systems can react. Inbound: identity flows can call out to your systems mid-journey for validation, data enrichment, or business checks. For example, an inbound check against a fraud service can decide whether to let a sign-up complete.

Capabilities Involved

• Emit identity events (sign-up, password change, and so on) to subscribers.
• Push new-user data to a CRM or marketing tool on sign-up.
• Send SMS and email notifications through providers you choose.
• Call out to your own systems mid-journey (validation, data lookup, and so on).
• Run checks before or after key identity actions.

Cross-Cutting Choices

Every implementation touches these regardless of which approach you pick.

• Application type: single-page web app, server-rendered web app, native mobile, or backend.
• Tokens: claim shape, lifetimes, and refresh strategy (access / ID / refresh tokens).
• Branding: applies to the identity product's hosted pages (redirect-based) and to the app's own screens (the app-native and direct-API approaches).
• Session model: token-based, or longer-lived "stay signed in" sessions.

---

Next Steps

Pick an approach that fits your application, then see it running with sample apps you can clone and run. (Sample tutorials coming soon.)