Authentification

Tous les appels à l'Engine API nécessitent un jeton Bearer obtenu auprès de l'Identity API.

POST /connect/token

Échange des identifiants client contre un jeton d'accès.

En-têtes :

Content-Type: application/x-www-form-urlencoded

Corps :

Champ	Requis	Description
grant_type	Oui	Doit être client_credentials.
client_id	Oui	Identifiant du client API, issu du portail.
client_secret	Oui	Secret du client API, issu du portail.

Exemple :

curl -X POST "$KUSTODYAN_IDENTITY_URL/connect/token" \
  -d "grant_type=client_credentials" \
  -d "client_id=$KUSTODYAN_CLIENT_ID" \
  -d "client_secret=$KUSTODYAN_CLIENT_SECRET"

Réponse (200) :

{
  "access_token": "eyJ...",
  "expires_in": 1800,
  "token_type": "Bearer",
  "scope": "rps_engine_api"
}

Les jetons sont de courte durée. Ils sont valables 30 minutes par défaut (expires_in vaut 1800 secondes). Envoyez-les toujours dans l'en-tête Authorization: Bearer <token> lors des appels à l'Engine API.

TIP

Mettez le jeton en cache dans votre application plutôt que d'en demander un nouveau à chaque appel, ce qui gaspille la capacité de l'Identity API. Renouvelez-le de manière proactive peu avant son expiration ; un renouvellement piloté par minuteur évite l'effet « thundering herd » lorsque les jetons de nombreux appelants expirent en même temps.

Limitation du client à un contexte

Les clients API émis depuis le portail peuvent être Global ou limités à un contexte.

Un client Global est utilisable sur l'ensemble des Rights Contexts, Processing Contexts et gestionnaires de secrets de la configuration.

Un client limité à un contexte est restreint à des Rights Contexts, Processing Contexts ou gestionnaires de secrets spécifiés. Utilisez des clients limités à un contexte lorsqu'une intégration n'a besoin que d'un ensemble restreint d'opérations, par exemple un client de protection seule qui peut écrire des valeurs protégées mais ne peut pas les déprotéger pour voir le texte en clair.