Relock with Auth0

It is a companion to the Relock Integration Guide, which describes the architecture, the relay, and the NGINX/Lua deployment that are the same for every provider. Read that guide first — or alongside this one — and return here for the Auth0 specifics.

Replace app.example.com throughout with the domain your application is served from (the domain the Relock relay sits in front of).

What Relock needs from Auth0. Unlike Okta and Entra, Auth0 does not expose a stable per-session claim on the access token by default. The relay therefore reads two namespaced custom claims — email and auth_time — that a Post-Login Action stamps onto the token (Step 3). Auth0 also issues an opaque access token unless an audience is requested, so the ALB action must ask for a decodable JWT (Step 4).

---

Step 1 — Application URIs

In the Auth0 dashboard: Applications → your application → Settings → Application URIs.

Step 2 — Tenant-level logout URL

In Tenant Settings → Advanced → Allowed Logout URLs, add:

• /https://app.example.com

Registering the logout URL at both the application and tenant level is what lets termination cascade through Auth0 to the SSO session (see Q2 in the main guide). Without it, a terminated session can silently respawn on the next request.

Step 3 — Post-Login Action

In Actions → Triggers → post-login, add an Action that stamps email and auth_time onto the access token as namespaced claims, so the relay can derive a stable anchor. (Okta and Entra expose the equivalent by default; Auth0 needs this Action.)

exports.onExecutePostLogin = async (event, api) => {
  const url = 'https://app.example.com/';
  if (!event.session) { return }

  api.accessToken.setCustomClaim(`${url}email`, event.user.email);
  api.accessToken.setCustomClaim(
    `${url}auth_time`,
    event.session.created_at
      ? Math.floor(new Date(event.session?.created_at).getTime() / 1000)
      : Math.floor(Date.now() / 1000)
  );
};

The relay matches these claims by suffix (.../email, .../auth_time), so the namespace prefix can be any URL you control — using your application domain, as above, keeps it self-documenting.

Step 4 — AWS Application Load Balancer

On the HTTPS (443) listener → Rules → Default rule, add an authenticate-oidc action ahead of the forward action (the mechanics are described in §5.2 of the main guide). Populate it with the values from Applications → your application → Settings → Advanced Settings → Endpoints.

Add an audience extra parameter. Under Authentication request extra params, add one key/value pair so Auth0 returns a decodable JWT access token rather than an opaque one:

Key	Value
audience	https://<your-auth0-domain>/api/v2/

This step is required for Auth0 only — Okta and Entra return decodable JWTs without it.

The ALB now sets its session cookie and injects x-amzn-oidc-accesstoken (plus x-amzn-oidc-data and x-amzn-oidc-identity) into requests reaching the NGINX target.

---

With Auth0 and the ALB configured, deploy the relay as described in the Relock Integration Guide → §5.2 The relay. No application code changes are required.