Actions

Account-security Actions and audience allowlists.

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 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.