⇧

Dossier d'Architecture logicielle - module Security - Intégration OIDC

Retour

Projet : Avenirs-ESR / ePortfolio.
Objet : Notes relatives à l’intégration OIDC

Révision : 1.0.0
Date : 20/12/2024
Auteur : A. Deman
Commentaire : Version initiale

Flows d’authentification

Actuellement deux types de flows d’authentification sont utilisés :

• Authorization Code Flow : redirection du client vers la mire CAS puis redirect vers callback du backend, récupération d’un code, redirection vers le client avec génération de l’access token.
  Plus sécurisé, les login/mots de passe ne transitent pas par le backend.
• Resource Owner Password Credentials (ROPOC) Flow. Moins sécurisé, utilisé uniquement dans cadre des tests unitaires pour récupérer un access token sans interraction.
  Les login/mot de passe transitent par le backend, sans être stockés.

A propos des claims

• Ce warning dans la doc CAS concerne les claims dans l’id token lorsque seul l’id token est demandé, sans access token (response type id_token).
• Dans notre cas le response type est “code” (Authorization Code Flow), on n’est donc pas dans le cadre strict de ce warning.
• Le paramètre cas.authn.oidc.id-token.include-id-token-claims=false ne change rien pour nous mais, par précaution, il est positionné malgré tout dans cas.properties.

Malgré cela, c’est une bonne pratique de n’utiliser l’access token uniquement comme jeton d’authentification et non comme conteneur d’identité.
L’access token doit donc être opaque et ne pas contenir d’information utilisateur. Ces informations sont ensuite récupérées via le end point userinfo ou profile.

JWT et claims

L’idée initiale était de continuer à utiliser le format JWT, avec un minimum de claims en limitant le scope à openid afin de pouvoir continuer à effectuer des vérifications de validité: signature, expiration, etc.
Cependant cette approche ne fonctionne pas car le scope utilisé pour obtenir l’access token conditionne également le détail des informations retournées par le endpoint profile.

Access token opaque

Le choix qui est fait est de ne pas utiliser le format JWT pour l’access token - propriété “jwtAccessToken”: false dans la définition du service cas.
Avec ce paramétrage, l’access token est opaque, c’est une chaine sans signification particulière et indépendante du scope utilisé (e.g.: openid profile email).
Les informations utilisateur peuvent ensuite être récupérées correctement via le end point profile.
Les vérifications de sécurité propre au JWT sont conservées mais désactivées via une propriété dans application.properties.

La validation de l’access token lors des utilisations ultérieures est réalisée par un appel au endpoint introspect de l’OIDC provider.