JWT Verification

Allegro issues signed JSON Web Tokens (JWTs) for every member session. Because these tokens are signed with an asymmetric RS256 key, you can verify them in your own infrastructure — AWS API Gateway, Cloudflare Workers, custom middleware — without any shared secret.

Getting the token in the browser

When you want your own backend to trust the visitor's Allegro session, read the raw JWT from the SDK and send it along as a bearer token. allegro.member.getJwt() returns the current session JWT as a string, or null when there is no valid token (the visitor is signed out, or the token is missing, malformed, or expired):

window.allegro.push(function (allegro) {
    const jwt = allegro.member.getJwt();

    if (jwt) {
        fetch('/api/user', {
            headers: { Authorization: `Bearer ${jwt}` },
        });
    }
});

Your backend then verifies the token against the tenant's public keys, exactly as described in the sections below — you don't need to share a secret with Allegro or call back to it to trust the token.

Token Structure

Every Allegro JWT has the following standard claims:

Claim	Description
iss	Issuer — your tenant domain (e.g. https://example.com)
aud	Audience — same as iss
sub	Subject — the member's UUID
iat	Issued at (Unix timestamp)
exp	Expires at (Unix timestamp, 1 year from issue)
jti	Unique token ID (UUID v4)

In addition, Allegro includes these custom claims:

Claim	Description
authenticated	true if the member has completed authentication
session.id	UUID of the AudienceDeviceSession
session.authenticated_at	ISO 8601 timestamp of when the session was authenticated
audience_member	Full member object (id, email, name, email_verified, …)
products	Array of product slugs the member currently holds active entitlements for
user_attributes	Object of the member's user attribute values, keyed by slug and cast to each attribute's type. Only attributes with a value appear; omitted entirely when the member has none

Token lifetime and revocation

A token stays valid until its exp claim — one year from when it was issued. Allegro also revokes a token as soon as the member logs out: the token's jti is recorded so it can no longer be used against Allegro's own session API.

The distinction matters if you verify tokens yourself:

• Calls to the Allegro session API (including anything the SDK does on the member's behalf) reject a revoked token immediately after logout.
• Your own stateless verification against the JWKS endpoint only checks the signature and exp. It has no way to know the member has since logged out, so a token you have already read stays cryptographically valid until it expires.

If your backend caches or trusts a JWT beyond a single request, treat the allegro:logout event as the signal to drop the token rather than relying on exp alone.

OIDC Discovery

Allegro exposes a standard OpenID Connect discovery document:

GET https://<your-tenant-domain>/.well-known/openid-configuration

This returns the issuer, JWKS URI, and supported algorithms. Most OIDC-aware services read this endpoint automatically.

JWKS Endpoint

Public keys used to verify token signatures are available at:

GET https://<your-tenant-domain>/.well-known/jwks.json

The response is a standard JWK Set containing one or more RSA public keys. Multiple keys may appear during key rotation — consumers must select the key matching the kid in the token header.

Example: AWS API Gateway JWT Authorizer

1. In your API Gateway HTTP API, add a JWT authorizer.
2. Set Issuer to your tenant domain: https://<your-tenant-domain>
3. Set Audience to your tenant domain: https://<your-tenant-domain>
4. Set JWKS URI to: https://<your-tenant-domain>/.well-known/jwks.json

AWS will automatically fetch the public keys and verify incoming tokens. No secret sharing required.