Passwordless Email OTP Sign-in

Overview

Passwordless Email Sign-in lets consumers access your application by entering their email address and a 6-digit verification code — no password is required. Both new and returning consumers follow the same single path: enter email, receive the code, enter the code, and sign in. This flow is ideal for email-only consumer audiences and any product where reducing sign-in friction is a priority. It differs from the standard B2C_1A_SignUpSignInLSG policy in that no password is ever created, collected, or stored — the verification code delivered to the consumer's inbox is the sole credential.

---

Authentication flow

The diagram below shows the complete sign-in journey from the moment a consumer enters their email address to the moment a signed JWT is issued to your application.

---

When to use this flow

Good fit

• Email-only consumer audiences — applications where consumers are identified by email and a password concept does not add value (e.g. subscription portals, loyalty programmes, booking confirmations).
• Passwordless-first consumer products — products deliberately designed to remove password management from the consumer experience.
• High-intent conversion flows — landing pages or campaigns where sign-in friction directly affects conversion rate and a fast, familiar email experience is preferred.

Not a fit

• SSO-required enterprise scenarios — where your organisation mandates corporate identity provider sign-in; use the standard B2C_1A_SignUpSignInLSG policy with SSO federation instead (see Authentication).
• Social identity provider as primary credential — where consumers expect to sign in with Google, Apple, or another social account as the primary option.
• roles claims required at sign-in time — the current release does not include role assignment in the token. If your application requires roles claims immediately on sign-in, refer to Deferred capabilities below and plan for Phase 2.

---

Enabling the flow for a tenant

Follow the steps below to enable passwordless email sign-in for a tenant application.

Step 1 — Configure verification code email fields on the tenant record

Set the following four fields on the tenant record in Tenant Management. These fields control how verification code emails are delivered and branded for this tenant.

Property	Purpose	Example value
emailOtpFromName	Sender display name shown in the consumer's email client	Acme Rewards
emailOtpFromAddress	Verified sender email address	noreply@acme-rewards.example.com
emailOtpTemplate	SendGrid dynamic template ID for the verification email	d-0a1b2c3d4e5f...
emailOtpSubject	Email subject line — should include the verification code for inbox preview	Your sign-in code: {{otp}}

tip

{{otp}} is the SendGrid dynamic template placeholder that the platform substitutes with the generated verification code at send time. You do not need to define or populate this variable yourself — include it in your subject or template body wherever you want the code to appear.

If any of these fields are absent, the platform falls back to a platform-level default SendGrid template and sender. See Verification code email template configuration for details on fallback behaviour.

Step 2 — Configure the client application to use the passwordless policy

Update B2CConfiguration.authority in the tenant's onboarding configuration to target B2C_1A_PasswordlessEmailOtpV2.

The policy URL pattern for each environment follows this format:

https://{b2cTenantName}.b2clogin.com/{b2cTenantName}.onmicrosoft.com/B2C_1A_PasswordlessEmailOtpV2

Replace {b2cTenantName} with the Azure AD B2C tenant name for the target environment. Contact the Apex platform team if you need the correct values for your environment.

Step 3 — Ensure tenantId is passed in the B2C authorization URL

The B2C_1A_PasswordlessEmailOtpV2 policy requires the Apex tenant identifier to be present in every authorization URL request. Pass it as a query parameter named tenantId — the policy reads this value and forwards it to the email delivery endpoint.

Example authorization URL (conceptual — values are illustrative):

https://{b2cTenantName}.b2clogin.com/{b2cTenantName}.onmicrosoft.com/B2C_1A_PasswordlessEmailOtpV2/oauth2/v2.0/authorize
  ?client_id=...
  &redirect_uri=...
  &scope=openid
  &tenantId={your-apex-tenant-id}

If tenantId is absent, the platform email endpoint cannot route the request to the correct tenant template and will fall back to the default sender and template.

Step 4 — Run the go-live checklist before production traffic

Before directing real consumer traffic to the passwordless flow, confirm the following:

1. OTP delivery test — trigger a sign-in via jwt.ms using your B2C configuration; confirm a verification code email arrives in your test inbox within a few seconds.
2. JWT validation — after completing the code entry step at jwt.ms, confirm the decoded token contains email, tenantId, and trustFrameworkPolicy: B2C_1A_PasswordlessEmailOtpV2.
3. Inbox placement confirmation — check that the email is not landing in spam; verify the emailOtpFromAddress is an authenticated sender in SendGrid.
4. Visual check — confirm the verification code entry page matches your tenant's brand; the page is controlled by the VerificationControl styles in platform.css (see Styling).

---

Verification code email template configuration

The four tenant configuration fields listed in Step 1 above map directly to the verification code email your consumers receive:

Field	What it controls
emailOtpFromName	The sender name displayed in the consumer's email client ("from" display name)
emailOtpFromAddress	The email address the message is sent from — must be a verified sender in SendGrid
emailOtpTemplate	The SendGrid dynamic template rendered as the email body
emailOtpSubject	The subject line of the email; include the code token ({{otp}}) so it appears in inbox previews — {{otp}} is replaced by the platform with the generated code at send time

Fallback behaviour

If any of the four fields are absent or blank on the tenant record, the platform uses its own default SendGrid template and sender details. The sign-in flow continues normally — no error is returned to the consumer and no 409 response is issued in the current release.

Phase 2

Strict tenant template validation — where the platform returns a 409 response when no tenant template is configured — is deferred to Phase 2. Until then, the platform default template acts as the fallback for all tenants without their own configuration.

The platform-level default template is branded generically. For any tenant where consumer brand consistency matters, configuring all four fields is strongly recommended before production go-live.

---

JWT claims reference

The table below lists all claims included in the JWT issued by B2C_1A_PasswordlessEmailOtpV2.

Claim	Description
sub	B2C subject identifier — unique per user per application registration
oid	B2C object ID — stable across applications; matches the Azure AD B2C directory entry
email	The consumer's verified email address as entered during sign-in
tenantId	The Azure AD B2C directory Object ID for the environment the policy is deployed to. This is a fixed per-environment value, the same for all tokens issued in that B2C tenant.
trustFrameworkPolicy	Always B2C_1A_PasswordlessEmailOtpV2 for tokens issued by this policy
roles	Not available in the current release. Role assignment requires the SSO-UserRoles orchestration step, which is deferred to Phase 2. See Deferred capabilities.

note

The otpCode value used internally during the sign-in flow is never emitted in the JWT. This is by design and enforced at the policy level.

---

Deferred capabilities

The following capabilities are planned for Phase 2 and are not available in the current release.

Capability	Reason deferred
roles claim in JWT	Requires the SSO-UserRoles orchestration step to be added to the policy UserJourney
Sign-in event logging	Requires the SSORestAPI-SignIn-log step to be added to the policy UserJourney
Strict tenant template validation (returns 409 when no tenant template configured)	Deferred to avoid blocking tenant onboarding during initial rollout; default template fallback used in the meantime

If your use case depends on any of these capabilities, contact the Apex platform team to understand the Phase 2 timeline.