Skip to main content

Login Flows

Login Flows​

This section illustrates the major authentication paths supported by Openlane.

Credential Login​

The credential handler is implemented in internal/httpserve/handlers/login.go:

  • LoginHandler parses a LoginRequest and calls getUserByEmail to fetch the account.
  • If the account does not exist, RegisterHandler creates the user and sendVerificationEmail dispatches the confirmation email.
  • ssoOrgForUser determines if the organization enforces SSO for the email and redirects non-owner users to SSOLoginHandler when required.
  • Unverified users can request a new token via ResendEmail, which invokes storeAndSendEmailVerificationToken.
  • When the password is validated with passwd.VerifyDerivedKey, AuthManager.GenerateUserAuthSession issues the access and refresh tokens and updateUserLastSeen records the login.

OAuth / Social Login​

The OAuth handlers are defined in internal/httpserve/handlers/oauth_login.go and oauth_register.go:

  • GetGoogleLoginHandlers and GetGitHubLoginHandlers redirect users to the provider.
  • After the provider callback, issueGoogleSession or issueGitHubSession call CheckAndCreateUser to create or update the user record.
  • ssoOrgForUser checks the email's organization and redirects to SSOLoginHandler when SSO is enforced for non-owner members.
  • New accounts are verified by sendVerificationEmail inside storeAndSendEmailVerificationToken.
  • A session is created via AuthManager.GenerateOauthAuthSession and the last login is stored with updateUserLastSeen.

Passkey Login​

Passkey operations live in internal/httpserve/handlers/webauthn.go:

  • BeginWebauthnLogin issues a challenge with WebAuthn.BeginDiscoverableLogin and stores it in the session.
  • FinishWebauthnLogin parses the response using protocol.ParseCredentialRequestResponseBody and validates it with WebAuthn.ValidateDiscoverableLogin.
  • The user is loaded with getUserByID, then AuthManager.GenerateUserAuthSession creates the token pair.
  • updateUserLastSeen records that the login was via a passkey.

Organization-Enforced SSO​

Single sign-on logic is implemented in internal/httpserve/handlers/sso.go:

  • SSOLoginHandler checks the organization policy via fetchSSOStatus and redirects to the configured IdP.
  • On return, SSOCallbackHandler exchanges the authorization code with rp.CodeExchange and retrieves the user data.
  • The account is ensured using CheckAndCreateUser; new users receive a verification email via sendVerificationEmail.
  • AuthManager.GenerateOauthAuthSession issues the session and the login time is recorded with updateUserLastSeen.

WebFinger Endpoint​

WebFinger is an HTTP discovery protocol defined by RFC 7033. It allows a client to look up information about a resource, typically identified by a URI such as an email address.

Openlane exposes a WebFinger endpoint at /.well-known/webfinger. The login page queries this endpoint to determine whether an organization requires SSO authentication and which identity provider should be used.

Querying the Endpoint​

Send a GET request to /.well-known/webfinger with a resource parameter.

/.well-known/webfinger?resource=acct:alice@example.com
/.well-known/webfinger?resource=org:01HAC1M7J3A2YHC4ZK6B2QWJNT

The endpoint returns an SSOStatusReply structure:

{
  "success": true,
  "enforced": true,
  "provider": "OKTA",
  "discovery_url": "https://id.example.com/.well-known/openid-configuration",
  "organization_id": "01HAC1M7J3A2YHC4ZK6B2QWJNT"
}

Why WebFinger?​

Using WebFinger provides a lightweight way for the UI to discover if SSO is enforced before the user authenticates. When the email entered on the login form maps to an organization that enforces SSO, the browser can immediately redirect to the configured identity provider without any additional API calls or user interaction.

OIDC Handler Flows​