Aller au contenu principal

Authentification et autorisation

401 Unauthorized​

Un 401 indique généralement que la requête ne dispose pas d'un token utilisable.

Vérifiez :

  1. la présence du header : 
    Authorization: Bearer <access_token>
  2. que le token n'est pas expiré ;
  3. que le token a été obtenu avec le bon client_id et le bon client_secret ;
  4. que vous n'avez pas mélangé des credentials provenant de deux environnements ;
  5. que le token envoyé est bien le dernier token généré par votre application.

Bon réflexe​

Ne recréez pas inutilement un token avant chaque appel. Réutilisez-le pendant sa durée de validité puis renouvelez-le avant expiration.

403 Forbidden​

Un 403 signifie que le serveur a identifié l'appelant mais refuse l'opération dans le contexte fourni.

Partner APIs​

Pour les routes tenant-scoped, vérifiez en particulier :

  • que le tenant appartient bien au partenaire ;
  • que le tenantSlug du chemin est correct ;
  • que le header de tenant attendu par le contrat est cohérent avec le tenant ciblé ;
  • que les droits associés au token permettent l'opération.

Tenant Public API​

Vérifiez :

  • Organization-Id lorsque le Swagger le demande ;
  • que la valeur correspond à l'organisation ciblée ;
  • que le token correspond au tenant concerné ;
  • que le legalUnitId, flowId ou autre identifiant appartient bien au même contexte.

User-Agent​

Lorsque le service le requiert, transmettez :

User-Agent: BCSolutions

Ce header ne remplace ni OAuth2 ni le contexte d'organisation.

Ne journalisez pas les secrets​

Pour diagnostiquer l'authentification, journalisez :

  • le client_id si votre politique le permet ;
  • la date d'expiration ou l'âge du token ;
  • le host appelé ;
  • le code HTTP ;
  • l'identifiant de corrélation.

Ne journalisez jamais :

  • le client_secret ;
  • l'access token complet ;
  • un secret bootstrap.

➡️ Authentification et headers