Authentication

The Eriga API accepts OAuth2 access tokens issued by the configured Identity Provider (IdP). Every request must carry a valid token; most requests must also identify a tenant with the X-Space-Id header.

Request shape

GET /units HTTP/1.1
Host: api.eriga.app
Authorization: Bearer <access_token>
X-Space-Id: 2f3a...-...

Element	Value
Authorization	Bearer <access_token> — JWT issued by the IdP
X-Space-Id	UUID of the target Space (tenant). Required on most endpoints

The X-Space-Id header is omitted on cross-space endpoints — for example GET /spaces, which lists the Spaces the caller can access.

Access tokens

Eriga validates JWTs via the JWKS endpoint exposed by the IdP. A token is accepted when:

• the signature verifies against the current JWKS,
• the iss claim matches the configured issuer,
• the aud claim contains https://compliance.eriga.app,
• the token is not expired,
• the sub claim carries the user identifier.

The sub claim is the stable user identifier used by Eriga for audit and membership lookups. Eriga does not read or store any other user profile information.

Tenant selection

Every write endpoint and most read endpoints scope data to a Space. The caller selects the Space by sending its UUID in the X-Space-Id header.

The backend validates that the user has access to the requested Space before processing the request. The response is:

• 401 Unauthorized if the token is missing, invalid, or expired,
• 403 Forbidden if the token is valid but the user has no access to that Space,
• the normal response otherwise.

Getting an access token

Interactive clients run the standard OAuth2 Authorization Code flow with PKCE against the IdP. The resulting access token is sent verbatim in the Authorization header.

Machine-to-machine clients use the Client Credentials flow or the OAuth2 Token Exchange (RFC 8693) when relaying on behalf of a user.

The IdP-specific endpoints (authorization_url, token_url, jwks_uri) are published by the OpenID Connect discovery document at:

${IDP_ISSUER}/oidc/.well-known/openid-configuration

Refer to your IdP’s documentation for the exact client registration steps.

What Eriga does not do

• Eriga does not issue tokens — authentication is delegated to the IdP.
• Eriga does not manage password reset, sign-up, or sign-in flows.
• Eriga does not store user passwords or credentials.
• Eriga does not persist user profile data — names and emails are fetched on-demand from the IdP when needed by the UI.