Traitement des jetons au porteur compromis

Les jetons OAuth Bearer sont utilisés pour accéder aux ressources protégées. Ils sont souvent utilisés pour offrir une preuve suffisante pour obtenir l'accès par l'utilisation de champs d'application ou de détails plus fins dans les demandes, comme authorization_details (Ref : Rich authorization request ). Cela signifie que si un acteur ou un système non autorisé accède au jeton porteur, il peut usurper l'identité de l'utilisateur (ou du système) et accéder aux ressources protégées. Le serveur de ressources n'a aucun moyen de vérifier que l'expéditeur du jeton de support est légitime tant que le jeton est valide.

Une solution consiste à exiger l'utilisation de jetons de preuve de possession qui permettent à un serveur de ressources de vérifier que le jeton de support est utilisé par un client légitime. Les jetons d'accès liés à un certificat sont un exemple de ces jetons.

Jetons liés à un certificat ou jetons mutuels TLS limités à l'expéditeur

Les jetons d'accès liés à un certificat (parfois également appelés jetons TLS mutuels limités à l'expéditeur) sont liés à la connexion TLS mutuelle sous-jacente entre le client et le serveur d'autorisation (comme IBM Security Verify ). Dans le cadre du flux d'octroi OAuth 2.0, la connexion sous-jacente au point final d'émission du jeton est sécurisée par TLS mutuel. Après l'établissement d'une connexion de transport réussie, le serveur d'autorisation encode l'empreinte du certificat du client et la stocke dans la concession d'autorisation dans le cadre de la demande de "confirmation" ( cnf ). Elle est ensuite mise à disposition dans le cadre de la réponse d'introspection du jeton ou incorporée dans un jeton d'accès formaté JWT.

Le processus est illustré dans le schéma ci-dessous. L'application (client) lance un flux de codes d'autorisation via le navigateur pour obtenir un code d'autorisation et l'utilise ensuite pour demander un jeton.

Voici un exemple de réponse d'introspection. La charge utile comprend la demande de confirmation.

{
  "active": true,
  "aud": [
    "6344df61-2fee-4429-9557-6b2979a138f7"
  ],
  "client_id": "6344df61-2fee-4429-9557-6b2979a138f7",
  "cnf": {
    "x5t#S256": "Rvc6LtXrtcjJsf0zZacc2MCETnUOWu59cz3H4ohh4-o"
  },
  "exp": 1679717794,
  "grant_id": "8fa20f0e-d98f-4659-8a55-bfa46293d7ac",
  "iat": 1679714193,
  "iss": "https://harbinger.verify.ibm.com/oauth2",
  "nbf": 1679714193,
  "scope": "profile openid",
  "sub": "671000CCGT",
  "token_type": "bearer",
  "token_use": "access_token"
}

Maintenant que le jeton a été émis, il peut être utilisé comme jeton porteur pour accéder à une ressource protégée.

Utilisation du jeton limité à l'expéditeur

Lorsque le client accède à une ressource protégée API autorisée à l'aide du jeton Bearer, il est désormais tenu d'utiliser le même certificat client pour établir une connexion TLS mutuelle. Cette application a lieu au niveau du point de terminaison de la ressource (ou au niveau de la passerelle API/proxy, où la connexion TLS se termine).

L'API (ou la passerelle) analyse le jeton (s'il ne s'agit pas d'un JWT) et effectue les opérations suivantes :

1. Générer l'empreinte encodée : La valeur est un hachage SHA-256 RFC4648 Base64URL-encodeda.k.a empreinte, empreinte digitale ou condensé) de l'encodage DER du certificat X.509.

// Importing crypto module
const {X509Certificate,createHash} = require('crypto');

// PEM-encoded X.509 certificate, usually extracted from the request object
const pem = '...';

// Getting object of a PEM-encoded X.509 Certificate.
const x509 = new X509Certificate(pem);

// Compute the thumbprint hash
const thumbprintHash = createHash('sha256').update(x509.raw).digest('base64url');

2. Introspecter le jeton Bearer ou valider le JWT (s'il est formaté de cette manière).

3. Extraire la valeur cnf.x5t#s256 et la comparer au hachage de l'empreinte calculé à l'étape 1. S'ils correspondent, d'autres décisions d'autorisation sont prises, comme la comparaison des champs d'application accordés, etc.

Conclusion

Les jetons d'accès liés à un certificat ajoutent une forte couche d'assurance en exigeant une preuve de possession par l'utilisation du certificat utilisé pour établir une connexion TLS mutuelle. Ils limitent l'utilisation abusive des jetons par des parties non autorisées. Les parties non autorisées comprennent les acteurs malveillants, les API de ressources ayant accès au jeton et qui le réutilisent pour accéder à d'autres points d'extrémité, etc. L'authentification mutuelle du client TLS et les jetons d'accès liés à un certificat conviennent aux environnements présentant des exigences de sécurité plus élevées, tels que les écosystèmes bancaires ouverts.

Les applications clients définies sur IBM Security Verify via OAuth 2.0 Dynamic Client Registration ou la console d'administration peuvent être configurées pour exiger Mutual TLS afin d'émettre des jetons d'accès liés à des certificats. Pour plus de détails, voir le connecteur d'application OpenID Connect.

💎

Vivek Shankar, IBM Security