My Account
Web-only My Account, multi-resource refresh tokens, and step-up.
The website MRRT policy includes the Shop API with website_api_scopes and, when enabled, My Account with
shop_my_account_scopes. Refresh rotation keeps zero leeway. Every website login requests the Shop API audience and
website scopes. Customer token acquisition coalesces per sid inside one isolate; separate isolates are not coordinated.
Auth0’s My Account API lets a signed-in user manage their own authentication methods. In this design it is web-only: the webshop calls it directly with the customer’s own My Account token. The Shop API has no My Account endpoints, never receives a My Account token, and is not in that call path.
Configure the built-in API
Activate Auth0’s built-in My Account API and verify its access and assurance policies before setting
enable_shop_my_account_api=true. Do not create a duplicate custom API. The two identifiers below have different
uses when the website has a custom login domain:
| Use | Identifier |
|---|---|
| Terraform user grant and website MRRT policy | https://<canonical-tenant-domain>/me/ — the registered system API identifier |
| Runtime token requests and My Account calls | https://<website-login-domain>/me/ — the custom-domain alias used at authentication time |
infra/terraform/auth0/shop.tf keeps these as shop_my_account_identifier and shop_my_account_audience.
The custom-domain alias is not valid in the grant or MRRT provisioning fields. Keep the trailing /me/ here;
the no-trailing-slash rule applies to the Shop API and MCP origins, not this built-in API.
Before using sensitive confirmations, set the My Account token lifetime to at most 300 seconds; the storefront
refuses longer-lived tokens. The website requests only the required My Account scopes, and Auth0’s canonical tenant
keys verify the result independently of the Auth0 proxy keys. Use the checkout’s infra/terraform/auth0/README.md for
the complete tenant settings and activation checks.
What stays in the webshop
- the Universal Components proxy for the account pages;
- security-method removal;
- recovery-code regeneration;
- passkey and MFA enrollment.
My Account tokens stay in the webshop’s server-side session. The webshop gates its proxy with the same customer-session check every account page uses (the Auth0 SDK cookie, checked against the shop’s revocation list).
Multi-resource refresh tokens
The website’s refresh token covers two audiences: the Shop API and My Account. The webshop asks the Auth0 SDK for an access token per audience, and refreshing one doesn’t require signing in again.
Step-up
Removal and recovery regeneration request prompt=login, max_age=0, the My Account audience and the exact resource scopes. They request no offline_access. The Actions reject refresh exchanges, a wider scope, another audience, a missing target digest and a stale credential or factor ceremony. OIDC scopes are removed from the access token so its resource scopes remain exact.
A step-up login returns a My Account access token, so the Shop API token never carries the proof and the Auth0 Action is unchanged. The callback therefore verifies the ID token against the tenant’s keys and hands its claims and the transaction nonce to the storefront’s own fresh-intent acceptance, which runs the account domain against the shop database. The intent and callback steps are ordinary account-security work before My Account execution, run in the storefront; only the Actions call the Shop API, to record and consume the challenge. No My Account operation calls the Shop API. A completed callback records step_up_accepted and erases its nonce and target; this is distinct from a pending provider mutation.
| Property | Enforcement | Test |
|---|---|---|
| Owned method only | Target is sealed before login and must occur in the bearer’s own method listing | step-up.test.ts, account-step-up.e2e.ts |
| Fresh proof for this operation | Actions check ceremony, purpose, subject, target digest, audience and exact scopes | Action tests and fresh-intents.server.test.ts |
| Single issuance and browser use | Action consumes the intent atomically; webshop clears the sealed cookie after mutation use | Action consume test and confirmation replay e2e |
| No browser-selected subject | Confirmation accepts only an operation id; sealed subject must match the customer | Foreign subject and operation tests |
| Recovery secret once | Returned only after My Account enrollment verification; never logged, persisted or put in a cookie | Recovery unit and e2e suites |
| Last credential and factor safety | Canonical policy is checked against the completed ceremony; live method listing is checked before removal | Policy refusal test and existing last-factor e2e |
fh_step_up is a versioned encrypted HttpOnly; Secure; SameSite=Lax; Path=/account cookie. Its lifetime is the smaller of provider token expiry and 300 seconds; provider tokens with a longer lifetime are refused. Server functions run under /account/_serverFn so browsers send this scoped cookie. It contains the operation, subject, purpose, target digest, target, policy and bearer. The step-up token is removed from the SDK token sets. Ordinary enrollment continues to acquire My Account tokens through MRRT.
The accepted residual risk is a stolen sealed cookie replayed before first use, within that short window. Cookie deletion refuses a later confirmation from the same browser; it cannot revoke a copy already stolen. The owner must configure the My Account token lifetime to at most 300 seconds before switching; longer tokens fail closed. The canonical tenant JWKS verifies these tokens independently of custom-domain Auth0 proxy keys.
Recovery replacement is not atomic: an existing recovery method is deleted before enrollment and verification. An uncertain write clears the credential and asks for new verification. The recovery secret is returned only in the action response. The My Account MFA Action may require a second factor even when the intent also requires fresh database credentials.
Auth0’s My Account reference documents recovery-code enrollment and verification with auth_session.