Authentication
Signup, login (password / passwordless / social), logout, password reset, verification, and change password.
Every call below is a method on NestAuthClient. Login and signup persist the returned tokens automatically, so a subsequent getSessionUserData() is authenticated without any extra wiring. Non-2xx responses throw NestAuthException.
Sign up
Register a new account with an email or phone plus a password. The returned AuthResponse carries the token pair, which is persisted for you:
The full signature accepts an optional tenantId and an extra map merged into the request body for app-specific signup fields:
Log in with email & password
The simplest path is loginWithEmail:
If the account has MFA enabled,
res.isRequiresMfaistrueand no tokens are stored yet — you must complete the challenge. See MFA & Tenancy.
For full control use login, which targets a named provider and takes a free-form credentials map:
Passwordless login
A two-step flow: send a one-time code to an email or phone, then exchange the code for a session.
Step 1 — send the code. channel is 'email' or 'sms', and identifier is the matching address:
Step 2 — verify the code. The user reads the code from their inbox / SMS and enters it; this persists tokens on success:
Social login (native — no browser)
Google and Apple sign-in use the platform's native flow. Get the token from google_sign_in / sign_in_with_apple, then exchange it with the NativeSignIn helpers (signInWithGoogleIdToken / signInWithAppleCredential), which handle the token type and assemble Apple's first-login name for you.
Set serverClientId to your web OAuth client ID so the returned ID token's audience matches the backend's google.clientId (or a google.audiences entry):
Apple
Apple returns the user's name only on the first sign-in — pass givenName/familyName so the backend can persist it. nonce is optional replay protection.
Backend config. Native Apple identityTokens are verified against Apple's JWKS — no client secret needed for mobile. Set
apple.audiencesto include your iOS Bundle ID alongside the web Service ID (clientId). For Google, add any native client IDs togoogle.audiences.
socialLogin remains available for a token you obtained another way:
The current session
After a successful login, fetch the signed-in user with getSessionUserData (GET /auth/me). The typed SessionUser exposes id, email, and phone; the full payload is on raw for any app-specific fields:
Log out
logout revokes the session server-side (best effort) and clears the local tokens regardless of the server response:
Password reset
A three-step flow for users who have forgotten their password.
Step 1 — request a code. Pass the account's email or phone:
Step 2 — verify the code. The response contains a token (also exposed as resetToken) to use in the final step:
Step 3 — set the new password using that token:
The signatures:
Change password
For a signed-in user who knows their current password:
Email verification
Two steps: send a verification code to the signed-in user's email, then verify the code they enter.
Phone verification
The same two-step pattern over SMS:
Next steps
- MFA & Tenancy — complete an MFA-gated login and switch tenants.
- Using it in your app — drive a reactive UI and handle errors.