Step-Up Authentication avec OpenID Connect

Qu’est-ce que la step-up authentication ?

La step-up authentication est un mécanisme de sécurité qui exige de l’utilisateur qu’il se réauthentifie avec un niveau de garantie plus élevé lorsqu’il accède à des ressources sensibles ou effectue des actions critiques. Elle garantit que l’utilisateur à l’origine de la demande dispose d’une identité vérifiée à la hauteur de la sensibilité de l’opération ou des données.

Par exemple :

• Un utilisateur qui se connecte à une application bancaire peut s’authentifier au départ avec un mot de passe pour consulter le solde de ses comptes.
• Pour effectuer un virement ou accéder au détail de ses comptes, il peut lui être demandé de fournir des facteurs d’authentification supplémentaires, comme un mot de passe à usage unique (OTP) ou une vérification biométrique.

Quand et pourquoi utiliser la step-up authentication ?

La plupart des applications utilisent un seul niveau d’authentification pour vérifier l’identité d’un utilisateur. Or, certains scénarios exigent des mesures de sécurité supplémentaires pour protéger des données ou des opérations sensibles. Pour autant, vous ne voulez pas imposer l’authentification multi-facteurs (MFA) à vos utilisateurs à chaque connexion ou à chaque accès à l’application. La step-up authentication offre un équilibre entre sécurité et facilité d’usage en n’exigeant une authentification supplémentaire que lorsque c’est nécessaire.

La step-up authentication est couramment utilisée dans les situations suivantes :

• Opérations sensibles : un niveau de sécurité plus élevé est nécessaire pour accéder à des ressources sensibles, comme des informations financières ou des données confidentielles.
• Conformité réglementaire : des standards comme PCI-DSS, HIPAA ou le RGPD imposent un niveau de garantie plus élevé pour certaines actions.
• Prévention de la fraude : elle permet de bloquer les acteurs malveillants qui ont dérobé des identifiants basiques lorsqu’ils tentent d’accéder à des systèmes ou des ressources critiques.

Mettre en œuvre la step-up authentication avec OpenID Connect (OIDC)

Si vous utilisez OpenID Connect pour l’authentification, vous pouvez mettre en place la step-up authentication en vous appuyant sur l’ID token et ses claims. L’ID token est un JSON Web Token (JWT) qui contient des claims sur l’événement d’authentification et sur l’utilisateur. En incluant des claims spécifiques dans l’ID token, vous pouvez imposer une step-up authentication selon le contexte de l’utilisateur ou l’opération demandée.

Step-up authentication avec le claim acr

La première chose à faire est de définir les différents niveaux d’authentification en établissant des Authentication Contexts. Ces contextes représentent la robustesse du processus d’authentification et permettent de déterminer quand une step-up authentication est nécessaire. Il s’agit d’un vocabulaire commun partagé entre le serveur d’authentification et l’application cliente.

Le claim acr (Authentication Context Class Reference) de l’ID token représente la référence de la classe de contexte d’authentification utilisée pendant le processus. Il indique le niveau de garantie apporté par l’authentification de l’utilisateur dans la session en cours. Par exemple : acr=loa1 représente un niveau de garantie basique, comme une authentification par mot de passe.

Lorsqu’un utilisateur s’authentifie, le serveur d’authentification inclut le claim acr dans l’ID token en fonction du niveau de garantie fourni. Votre application peut alors évaluer ce claim pour déterminer si une step-up authentication est nécessaire pour l’opération demandée.

OpenID Connect définit des valeurs courantes pour le claim acr, mais vous pouvez définir des valeurs personnalisées selon les besoins de votre application. La valeur la plus courante est http://schemas.openid.net/pape/policies/2007/06/multi-factor, qui indique qu’une authentification multi-facteurs a été utilisée lors du processus d’authentification.

Exemple de scénario de step-up authentication

Prenons le cas d’un utilisateur qui se connecte à une application pour consulter le solde de son compte. Le processus d’authentification initial utilise une méthode par mot de passe. Lorsque l’utilisateur tente d’effectuer un virement, l’application exige une step-up authentication et lui demande de fournir un mot de passe à usage unique (OTP).

1. L’utilisateur se connecte avec son nom d’utilisateur et son mot de passe. L’application envoie une requête d’authentification au provider OpenID Connect comme suit :

GET /authorize?
  response_type=code
  &client_id=client_id
  &redirect_uri=https://app.example.com/callback
  &scope=openid
  &state=state
  &nonce=nonce

Après une authentification réussie, le provider OpenID Connect émet un ID token avec le payload suivant :

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "exp": 1635200000,
  "iat": 1635196400,
  "amr": ["pwd"]
}

2. L’utilisateur lance une opération de virement. L’application évalue le claim amr de l’ID token et constate que l’utilisateur s’est authentifié avec un mot de passe. Comme l’opération requiert un niveau de garantie plus élevé, l’application demande à l’utilisateur de fournir un OTP.

L’application envoie une nouvelle requête d’authentification au provider OpenID Connect, avec le paramètre acr_values défini à http://schemas.openid.net/pape/policies/2007/06/multi-factor :

GET /authorize?
  response_type=code
  &client_id=client_id
  &redirect_uri=https://app.example.com/callback
  &scope=openid
  &state=state
  &nonce=nonce
  &acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor

Le provider OpenID Connect émet alors un nouvel ID token avec le payload suivant :

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "exp": 1635200000,
  "iat": 1635196400,
  "amr": ["pwd", "otp"],
  "acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor"
}

Vous pouvez désormais imposer la step-up authentication en vous basant sur le claim acr de l’ID token. En évaluant ce claim, vous déterminez à quel moment demander des facteurs d’authentification supplémentaires à vos utilisateurs.