--- title: My Account description: Web-only My Account, multi-resource refresh tokens, and step-up. sidebar: order: 5 --- 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:///me/` — the registered system API identifier | | Runtime token requests and My Account calls | `https:///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. ```mermaid sequenceDiagram participant W as Webshop participant DB as Shop database participant A as Auth0 Actions participant API as Shop API participant MA as My Account W->>DB: Create ordinary fresh-operation intent and capture policy W->>A: Fresh login, exact audience and scopes, signed target digest A->>API: Record completed challenge and atomically consume issuance A-->>W: ID proof and new My Account token W->>W: Verify the ID token against the tenant keys W->>DB: Accept fresh intent with the transaction nonce DB-->>W: Canonical policy for completed ceremony W->>W: Remove token from SDK session and seal fh_step_up W->>MA: List the token subject's methods W->>W: Check bound target and remaining credential policy W->>MA: Remove bound method or replace and verify recovery code W->>W: Clear fh_step_up in the same response ``` 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](https://auth0.com/docs/manage-users/my-account-api) documents recovery-code enrollment and verification with `auth_session`.