Tokens

TOSIAM supporte deux modèles de tokens OAuth2 : stateful (stockés en CTS) et stateless (JWT autonomes). Le choix impacte la scalabilité, la révocation et la latence de validation.

Tokens stateful (CTS)#

Par défaut, les access tokens sont des références opaques stockées dans le Core Token Store (CTS). La validation d’un token stateful nécessite une requête au CTS.

Avantages : révocation immédiate, pas de risque de fuite de données dans le token.
Inconvénients : chaque validation = requête LDAP, le CTS est un point central.

Tokens stateless (JWT)#

Les tokens JWT sont auto-porteurs : un serveur de ressources peut les valider en vérifiant leur signature avec le JWKS, sans appeler TOSIAM.

TOSIAM enregistre tout de même dans le CTS les métadonnées de chaque jeton stateless émis, et tient une liste de révocation : un jeton révoqué est refusé par TOSIAM (introspection, userinfo), mais pas par un serveur de ressources qui ne fait que vérifier la signature.

Avantages : validation locale, adapté aux microservices distribués, meilleure scalabilité.
Inconvénients : un serveur de ressources qui valide localement ne voit pas les révocations (le jeton reste accepté jusqu’à son expiration), taille plus grande.

Anatomie d’un access token JWT TOSIAM#

L’émetteur (iss) est l’URL OAuth2 du royaume : https://<serveur>/tosiam/oauth2 pour le royaume racine, https://<serveur>/tosiam/oauth2/<royaume> pour un sous-royaume. L’audience (aud) est le client_id du client qui a obtenu le jeton.

{
  "sub": "alice",
  "iss": "https://tosiam.example.com/tosiam/oauth2",
  "aud": ["mon-client"],
  "exp": 1735689600,
  "iat": 1735686000,
  "jti": "a1b2c3d4-e5f6-...",
  "scope": "openid email profile api:read",
  "client_id": "mon-client",
  "realm": "/",
  "cnf": {
    "x5t#S256": "cert-thumbprint"
  }
}

Clés de signature (JWKS)#

GET /oauth2/{realm}/connect/jwk_uri

Les clients doivent récupérer le JWKS dynamiquement (ou le mettre en cache et le recharger quand une signature ne se vérifie pas), pour suivre un changement de clé.

Tokens Macaroon#

TOSIAM supporte les tokens Macaroon : tokens porteurs avec caveats ajoutables sans interaction serveur. Un Macaroon peut être restreint (caveat first-party) par n’importe qui possédant le token.

# Inspecter un Macaroon
POST /oauth2/{realm}/macaroon/inspect
token=MACAROON_TOKEN

# Restreindre un Macaroon (ajouter un caveat)
POST /oauth2/{realm}/macaroon/restrict
token=MACAROON_TOKEN&caveat=time < 2024-12-31

Tokens Refresh#

Le refresh token est émis avec l’access token pour les grant types qui le supportent (authorization_code, password, CIBA). Sa durée de vie est configurable indépendamment.

Configuration des tokens stateless#

Dans la configuration du service OAuth2 du realm :

Realm → Services → OAuth2 Provider
  → Use Stateless Access & Refresh Tokens : Enabled
  → Signing Algorithm : RS256 (ou ES256)
  → Token Signing Key Alias : (alias de la clé dans le keystore)