Authentification et headers

OAuth2

Les APIs protégées utilisent OAuth2 avec un jeton Bearer. Le mode principal d'intégration serveur-à-serveur est le grant client_credentials.

POST /realms/bcs/protocol/openid-connect/token
Content-Type: application/x-www-form-urlencoded
User-Agent: BCSolutions

client_id=<client_id>&client_secret=<client_secret>&grant_type=client_credentials

Le token retourné est transmis sur les appels protégés :

Authorization: Bearer <access_token>
User-Agent: BCSolutions
Accept: application/json

Règles de sécurité

• Ne jamais transmettre un client_secret dans une URL, un log applicatif ou un message d'erreur.
• Renouveler le token avant expiration lors des traitements longs.
• Ne pas construire de logique métier à partir du contenu interne du JWT ; s'appuyer sur le contrat API et les scopes attribués.

Headers courants

Header	Usage
Authorization	Bearer token OAuth2
User-Agent	Header requis par les mécanismes d'accès BCSolutions ; valeur attendue : BCSolutions
Content-Type	application/json pour les payloads JSON ; multipart/form-data pour certains dépôts
Accept	Type de réponse attendu
Request-Id	Corrélation technique, notamment Flow Service
Organization-Id	Organisation cible lorsque requis par l'API

User-Agent

User-Agent participe aux mécanismes de protection des APIs. Il ne remplace ni l'authentification OAuth2 ni les headers de contexte requis.

Exemple tenant-scoped

POST /v1/onboarding/legal-units
Authorization: Bearer <access_token>
User-Agent: BCSolutions
Organization-Id: acme-fr
Content-Type: application/json
Accept: application/json