What Is User Authentication? Methods, Factors and How It Works

User authentication is the process of verifying that a person or workload is the identity it claims to be. A system checks one or more authenticators—such as a password, passkey, one-time code or enterprise identity-provider assertion—before it establishes a session. Authentication answers “who is this?”; authorization decides what that identity may do.

Key takeaways

• Authentication verifies identity; authorization evaluates access.
• A factor is the type of evidence used. A method is the mechanism that carries or verifies that evidence.
• Two checks from the same factor category do not automatically constitute MFA.
• A successful sign-in normally creates a session; tokens and cookies are ways to represent or carry session state, not authentication methods by themselves.
• B2B SaaS authentication must account for tenant-specific SSO and MFA requirements, plus recovery and session policies.

How user authentication works

The exact flow varies, but most systems perform four jobs.

1. Enroll or bind an authenticator. The service associates an authenticator with an account. That might mean registering a password verifier, binding a passkey, or linking an enterprise identity provider.
2. Request and verify evidence. At sign-in, the user proves control of the authenticator. The verifier checks the password, cryptographic response, one-time code or signed identity-provider assertion.
3. Establish a session. After successful verification, the application creates a session or accepts tokens from a trusted authorization server. The result should be scoped, time-limited and protected in transit and at rest.
4. Reauthenticate or terminate. Risk, sensitive actions, expiry, logout or administrative revocation can require fresh authentication or end the session.

This process is different from identity proofing. Identity proofing establishes that a real-world person corresponds to an identity record. Authentication later verifies control of an authenticator bound to that record.

Authentication factors

NIST groups authenticators by the evidence they use:

• Something you know: a password or PIN.
• Something you have: a device, hardware security key, smart card or authenticator app.
• Something you are: a biometric characteristic used to unlock or activate an authenticator.

Multi-factor authentication uses evidence from more than one factor category. A password plus two knowledge questions is still one factor category. Biometrics also need careful treatment: they are not secret and, in modern authenticators, often activate a device-held cryptographic key rather than being sent to the service as a reusable credential.

Common authentication methods

No method is strongest in every context. The right choice depends on threat model, user population, recovery requirements, device support and the damage an account takeover could cause.

Sessions, cookies and tokens

Authentication is the event; a session is how an application remembers its result. A traditional web application may keep session state on the server and place an opaque identifier in a secure cookie. Distributed applications may use access tokens that APIs validate locally or by introspection.

A JSON Web Token is a format, not a security guarantee. JWTs are commonly signed so recipients can detect modification, but they are not inherently encrypted. Applications must validate the expected issuer, audience, signature, expiry and other required claims. An ID token tells an OpenID Connect client about an authentication event; an access token is intended for an API. They should not be treated as interchangeable.

Browser storage is part of the threat model. JavaScript-readable storage can expose tokens to cross-site scripting. For browser sessions, teams should evaluate secure, HttpOnly, appropriately scoped cookies and CSRF protections instead of assuming local storage is the default.

Authentication protocols developers should know

OpenID Connect

OpenID Connect is an identity layer built on OAuth 2.0. It lets a client verify an authentication performed by an authorization server and obtain claims about the user. It is widely used for web, mobile and federated sign-in.

OAuth 2.0

OAuth 2.0 is an authorization framework. By itself it does not define how to authenticate an end user. Applications that need login commonly use OAuth 2.0 together with OpenID Connect.

SAML

SAML carries signed assertions between an enterprise identity provider and a service provider. It remains common for workforce SSO. Implementations need explicit controls for issuer, audience, destination, signature and certificate rotation.

WebAuthn

WebAuthn lets a site register a public-key credential and later verify a challenge signed by the corresponding private key. Because credentials are scoped to the legitimate site, passkeys built on WebAuthn resist credential phishing better than reusable passwords and one-time codes.

Authentication versus authorization

Authentication establishes an identity context. Authorization evaluates whether that identity may perform an action on a resource.

In a multi-tenant SaaS product, one person may authenticate once and belong to several customer accounts. The application must still authorize every action against the active tenant, membership, role and entitlement. A valid login does not imply access to every tenant the identity can name—or even to every feature inside the selected tenant.

Choosing authentication for B2B SaaS

B2B authentication is rarely one universal login flow. A practical design answers these questions:

1. Who controls the identity? Some users authenticate directly; enterprise customers may require their own IdP through SSO.
2. Which policy belongs to each tenant? Frontegg tenants can configure their own SAML or OIDC connection. Account administrators can also enforce a stricter MFA policy and adjust remember-device settings in the self-service portal when the Security module is enabled. If a user belongs to several accounts in one application, Frontegg applies the strictest applicable MFA rule during sign-in.
3. Which actions need step-up authentication? Changing billing, security settings or administrators may justify recent or stronger authentication. Frontegg’s step-up flow uses the standard acr, amr and auth_time claims to determine whether a user needs additional verification or fresh authentication.
4. How does recovery work? Recovery must not become an easier route around the primary method. Include lost devices, unavailable IdPs and departing administrators.
5. How are sessions revoked? Plan for logout, password reset, user suspension, membership removal and security incidents. Treat membership state and session revocation as separate controls: do not assume that removing an account membership automatically invalidates every previously issued token.
6. Can operations be audited? Record sign-in, failed attempts, factor enrollment, recovery and administrative policy changes with enough context to investigate them.

Tenant discovery is especially important. Before redirecting a user to an enterprise IdP, the application needs a trustworthy way to determine which organization and SSO configuration apply. Email-domain discovery can help, but verified domains, explicit organization selection and account-linking controls are needed to avoid assigning users to the wrong tenant.

Implementation checklist

• Define user, organization, membership and session as separate records.
• Use established OIDC, SAML and WebAuthn libraries instead of implementing protocol verification from scratch.
• Validate token issuer, audience, signature, expiry and application-required claims.
• Rate-limit authentication and recovery endpoints without creating an easy denial-of-service path.
• Offer phishing-resistant methods for administrators and high-impact actions.
• Test recovery, IdP outage, certificate rotation, clock skew, logout and revocation.
• Keep tenant selection and tenant-scoped authorization explicit after login.
• Log authentication events without recording passwords, raw secrets or reusable tokens.
• Review session duration, inactivity, refresh and concurrent-session policies.
• Provide a safe migration path when customers enable or disable enterprise SSO.

Implementing authentication with Frontegg

Frontegg provides hosted and embedded sign-in experiences for B2B applications. Its public documentation covers password sign-in, email magic code and magic link, SMS, passkeys, social login, and enterprise SSO through SAML and OIDC. Each tenant can configure its own SAML or OIDC connection through the self-service admin portal. Account administrators can enforce stricter MFA requirements and adjust remember-device settings when the relevant Security module is enabled. Teams can also configure session limits, revoke sessions, and validate tokens in supported backend SDKs or through the published signing keys.

After authentication, Frontegg’s token template includes the active tenantId; tenant-scoped roles and permissions can also be included for backend authorization checks. Applications should validate the token and bind every protected resource decision to that tenant context, not accept a role claim as tenant-independent authority. Users who belong to several tenants can switch the active tenant through the SDK’s switchTenant operation.

These capabilities still require product decisions. Teams must define how existing identities are linked, which operations require stronger authentication, and how authorization is enforced after login. Frontegg handles authentication infrastructure; the application remains responsible for its resource model and business rules.

Start with the authentication product overview, then use the Frontegg quickstart and the documentation for tenant SSO, account-level MFA, JWT claims, tenant switching, step-up authentication and session management for implementation details.

References

• NIST SP 800-63-4: Digital Identity Guidelines
• NIST SP 800-63B-4: Authentication and Authenticator Management
• OpenID Connect Core 1.0
• OWASP Session Management Cheat Sheet