Console sign-in and workspace access

Use /console/login when you already have access to a Paybond workspace. It is the sign-in entry point for workspace owners and invited operators across every plan.

If the workspace does not exist yet, start with signup instead.

Which plans use sign-in

Existing members of these plans sign in through /console/login:

Sign-in vs. signup

Use /console/login when:

• the user already belongs to a provisioned workspace
• the user was invited into an existing tenant
• the user is returning to the console, onboarding flow, or operator workspace

Use another entry point when:

• /signup is needed to create a new Free Developer, Starter, Team, or Business workspace
• /contact/sales is needed before custom / sales-led provisioning exists

The rule is simple:

• /signup creates a workspace
• /console/login opens an existing workspace

Session and access model

The console keeps authentication and tenant scope on the server side. After a user signs in, Paybond establishes the session, resolves the workspace and role set, and applies those permissions to subsequent console requests.

Workspace SSO

Business and Custom (sales-led) workspaces can use workspace SSO where the plan and tenant configuration enable it. Free Developer, Starter, and Team workspaces use Paybond-native sign-in and cannot configure tenant IdP federation. The login page keeps the operator-facing flow protocol-neutral: users enter the workspace realm, and Gateway starts the configured OIDC or SAML flow for that realm.

Tenant admins manage SSO from /console/configuration/identity/sso.

For OIDC:

• configure the IdP issuer URL, client ID, and client secret
• register /v1/auth/sso/callback as the redirect URI
• request openid email profile

For SAML:

• configure the tenant with the IdP metadata URL
• import Paybond SP metadata from /v1/auth/sso/metadata, or configure the ACS URL /v1/auth/sso/callback manually
• use the Paybond SP entity ID shown in the SSO setup page
• send a stable subject plus an email assertion for first login

In both protocols, Gateway stores single-use state before handoff and resolves tenant scope from that state and the configured realm after callback. SSO setup remains tenant-admin gated because it can change which external identities receive workspace access.

Keep me signed in (KMSI)

The sign-in and SSO panels on /console/login include an optional Keep me signed in on this device checkbox (KMSI). It only changes how long the console's own session cookies persist in the browser — it does not change how the identity provider authenticates the user.

What KMSI does and does not do

• Unchecked (default): the console sets paybond_access and paybond_refresh as browser session cookies (no Max-Age). They disappear once the browser fully closes that profile.
• Checked: the console sets the same cookies with an explicit Max-Age, so they survive browser restarts on that device.
• In both cases the cookies are HttpOnly, Secure outside local loopback, and SameSite=Strict (__Host--prefixed outside loopback). KMSI never relaxes those flags.
• KMSI does not configure or bypass identity-provider MFA, step-up auth, or "trusted device" state. Workspace SSO tenants keep whatever MFA and session policy their IdP enforces; KMSI only affects the Paybond console's own cookie, never the IdP's session.
• KMSI is not a device-binding or device-trust mechanism. Anyone with access to that browser profile while the cookie is alive can use the session — do not select it on a shared or public computer.
• KMSI does not change how long the underlying refresh token is valid for; see Relationship to the Gateway refresh token.

SAML ACS requires HTTPS locally

SAML responses land on POST /v1/auth/sso/callback, which is always a cross-site POST from the identity provider back to the console. The KMSI choice and the post-login return path travel through short-lived bridge cookies (paybond_pending_session_persistent, paybond_pending_sso_return_to) that must survive that round trip.

Browsers only send cookies cross-site when they are SameSite=None, and SameSite=None requires Secure — this is a browser rule, not a Paybond choice, and there is no workaround for it. Paybond will not set Secure cookies on plain HTTP, so:

• On any HTTPS origin (production, or a properly configured local HTTPS setup), the bridge cookies use SameSite=None; Secure and survive the SAML POST normally.
• On insecure local HTTP loopback (http://localhost, http://127.0.0.1), the bridge cookies fall back to SameSite=Lax, which browsers drop on a cross-site POST. Sign-in still completes, but the KMSI selection and return path silently reset to their defaults (KMSI off, return to /console).
• The admin app logs an admin_sso_insecure_saml_bridge_cookies warning on every SAML callback served in that mode, so the drop is visible in server logs instead of failing silently. This is observability only — it does not change cookie flags or weaken production security.
• To exercise KMSI against SAML locally, serve the console over HTTPS (mkcert, a local reverse-proxy tunnel, or another local HTTPS setup) and point PAYBOND_PUBLIC_BASE_URL at that HTTPS origin. OIDC callbacks arrive as a top-level GET redirect, which SameSite=Lax still allows, so plain HTTP loopback is sufficient for testing OIDC KMSI locally.

Browser session restore is outside app control

Some browsers restore previously open tabs — including authenticated console tabs — when the browser process relaunches (for example, "continue where you left off" or a crash-recovery prompt). If the console's session cookie was still valid at that moment, the restored tab appears signed in even when KMSI was left unchecked, because the browser process never actually ended the session cookie's lifetime.

This happens inside the browser before any Paybond code runs on the page. There is no reliable, non-brittle way for a web app to detect or prevent it, and Paybond does not attempt to fingerprint or block browser session restores. Operators on shared or public computers should sign out explicitly from the console rather than relying on KMSI being unchecked or the tab being closed.

Relationship to the Gateway refresh token

Gateway mints a refresh token on every successful sign-in — password, email code, or SSO — with a fixed lifetime (PAYBOND_REFRESH_TOKEN_TTL_DAYS, defaulting to 14 days) regardless of the KMSI choice. Gateway has no concept of "remember me"; only the admin app's cookie attributes change:

• KMSI unchecked: the refresh cookie is a browser session cookie, but the token it carries is still valid for the full refresh TTL. If the browser process stays alive — including via the session-restore behavior above — the console keeps refreshing access tokens off that same refresh token until it expires or is rotated.
• KMSI checked: the refresh cookie additionally gets an explicit Max-Age up to the same refresh TTL, so it also survives browser restarts on that device.
• Either way, the outer bound on session lifetime is the refresh token TTL, not the KMSI checkbox. This is by design: Gateway issues the refresh token before it learns the console's cookie-persistence choice, and shortening the default TTL for non-persistent sessions would change every session's lifetime (SSO and non-SSO alike), not just non-persistent ones. Tenants that need a shorter outer bound should lower PAYBOND_REFRESH_TOKEN_TTL_DAYS; signing out from the console revokes that specific refresh token immediately regardless of the KMSI choice.

After sign-in

Signing in does not mean every console surface becomes available immediately. After authentication:

• RBAC determines which routes the principal may open.
• Plan features determine which private surfaces are enabled.
• Gateway and Harbor still enforce tenant scope and commercial limits on every protected call.

In practice:

• All existing plans can sign in.
• Only entitled roles and enabled plan features can use specific console surfaces.

Related

• Self-serve signup and plan selection
• Paybond platform overview
• Operational surfaces