Request flows
Trace a request across tenant and service boundaries.
These flows show where OpenIssuer resolves tenant context, authenticates a user, enforces administrative scope, and changes service discovery between local development and Kubernetes.
OIDC authorization code
A tenant host controls the complete sign-in context.
The application starts a standard authorization-code flow with PKCE. OpenIssuer resolves the tenant from the issuer host before authenticating the user or loading client data.
1Client applicationRedirects the browser to the tenant /oauth2/authorize endpoint.
2Authorization serverResolves the issuer host and loads tenant-specific clients, keys, and authorization state.
3Authentication serviceVerifies credentials while account and attempt services enforce account state and login policy.
4Tenant boundaryConfirms user, default organization, and OAuth client belong to the current tenant context.
5Client callbackReturns the code, validates PKCE, and exchanges it for tenant-scoped tokens.
Tenant resolution
Hostnames select tenant data before authorization decisions run.
Public issuer and admin hosts are normalized to the organization tenant host. Tenant-specific authorization data stays in the matching database while shared profile and organization services enforce membership.
1Incoming hostfree.openissuer.com or business1.openissuer.com identifies the issuer.
2Host resolverNormalizes issuer and admin hosts to the configured tenant host.
3Tenant componentsSelects the tenant client repository, signing keys, authorizations, consent, and passkeys.
4Organization serviceResolves host-to-organization mappings and validates default organization access.
5Token claimsEmits issuer and tenant_id values for the resolved host.
Passkey MFA
Passkeys extend the authenticated tenant session.
Passkey management requires an authorization-server session. During sign-in, users with an enrolled credential complete a WebAuthn challenge before token issuance continues.
1Your ProfileLinks the signed-in user to the tenant /mfa/passkeys page.
2Session checkRedirects unauthenticated requests through sign-in instead of returning a raw bearer 401.
3Credential optionsCreates registration or authentication options for the current tenant and user.
4AuthenticatorUses a platform biometric or cross-device QR flow to prove possession.
5Authorization continuesRecords the factor and resumes the OAuth authorization request.
Administrative scope
Role assignments decide how much tenant data an admin can see.
Authentication establishes identity. Role assignments then scope administrative access to one organization or to all organizations mapped to a subdomain.
1AuthzManager sessionSigns the administrator in through the matching tenant issuer.
2Role serviceChecks OrgAdmin assignments by organization and SubdomainAdmin assignments by subdomain.
3Organization serviceValidates organization-to-subdomain mappings before returning scoped data.
4User serviceReturns organization users or paged users across the authorized subdomain.
5Admin viewShows organization controls and the subdomain menu only when the assignments allow them.
Service routing
Local and Kubernetes environments use different discovery paths.
The application contract stays the same while WebClient configuration changes how service names are resolved. Token calls can remain direct when HTTPS requires a concrete issuer URL.
1Local eurekaServices register on port 8761 and load-balanced WebClients resolve Spring service IDs.
2Local HTTPSKeeps Eureka for service calls while token and issuer calls use direct trusted HTTPS URLs.
3Kubernetes GatewayHTTPRoutes match public hostnames and path prefixes at the cluster edge.
4Non-Eureka servicesDirect WebClients call Kubernetes Service DNS names in the configured namespace.
5Application databaseEach service connects to its CloudNativePG writable service and applies Flyway migrations.