RS256 JWT-based SSO

How it works

1. User authenticates with your IdP (Auth0, Okta, Azure AD, etc.).
2. IdP signs an RS256 JWT containing the user's email and identity claims.
3. IdP redirects the browser to https://your-domain/sso/callback?org=<ORG_ID>&token=<JWT>.
4. KNMI Events verifies the signature against your JWKS / public key.
5. Validated claims (iss, aud, exp, iat) → user is provisioned & signed in.

Configuration

In Organization Settings → SSO set:

• Issuer — must match the iss claim in the JWT.
• Audience — must match the aud claim.
• JWKS URL — your IdP's .well-known/jwks.json endpoint (recommended; supports key rotation).
• Public Key PEM — alternative to JWKS, for static keys.
• Email claim — defaults to email.
• Name claim — defaults to name.

Required JWT claims

{
  "iss": "https://your-idp.com/",
  "aud": "knmi-events",
  "sub": "user-id-from-idp",
  "email": "user@example.com",
  "name": "Jane Doe",
  "iat": 1700000000,
  "exp": 1700003600
}

Tokens older than 5 minutes (by iat) are rejected.

Provider examples

Auth0

Use a custom Action to mint an RS256 JWT and redirect to the callback URL after login.

Okta

Configure an OIDC app and use the ID token (already RS256). Set the audience to your KNMI Events org identifier.

Azure AD

Register an Enterprise App, expose an API, and request the resulting access token (RS256).

Security

• RS256 = asymmetric. We never need your private key.
• JWKS responses are cached 5 minutes server-side.
• Strict claim validation (issuer, audience, expiry, not-before, iat skew).
• All login attempts are logged in sso_login_events for audit.