---
title: Actions
description: Account-security Actions and audience allowlists.
sidebar:
  order: 6
---

Two website-only post-login Actions enforce step-up for account-security operations
(`actions/shop-account-security.js` for the challenge and `actions/shop-account-security-proof.js` for the proof). They
allow the My Account, Shop API (`SHOP_API_AUDIENCE`) and UserInfo audiences for ordinary signed intents; an absent
secret allows no new audience. A `step_up: "my-account"` intent is narrower: only the My Account audience, its exact
operation scopes, no offline access and no refresh protocol. The local audience suite
(`shop-account-security.audience.test.ts`) checks both Actions against allowed resources, MCP denial, missing-secret
denial and no-intent behaviour.

## Security-intent endpoint

Both Actions call the API's `/internal/account/security-intents` at `SHOP_API_ORIGIN`, behind the shared Action secret.
The Terraform variable `shop_account_security_api_origin` defaults to `shop_api_origin`; the storefront has no
receiver. The endpoint is an oRPC procedure: a wrong secret is 401, a body over 8 KiB is 413 and an invalid receipt is
409, all `application/problem+json`; the Action only checks that the status is 2xx and reads `valid` and
`requiredAuthentication`. A completed challenge is consumed once before proof issuance.

## Operation-bound issuance

`mfa-remove` permits exactly read and delete authentication-method scopes; `recovery-regenerate` also permits create. The signed target digest is copied into the proof, alongside the resource scope set. The proof Action validates completed credentials or an existing factor, then sends `stage: consume` to the internal receiver. A second issuance with the same intent is refused. `api.accessToken.removeScope` removes OIDC scopes from this resource token.

The challenge Action must run before the proof Action in the post-login trigger; check the order in the tenant after
a release (it is on the acceptance checklist). See
[My Account](/architecture/auth0/my-account) for the accepted cookie replay window.

## Release order

A change to an Action and its receiver follows the three-release pattern: expand with the receiving side, switch the
consumer, then contract. See [Deployment](/architecture/deployment).