2.1.6. OIDC pour OpenID Connect
Au niveau du protocole
OAuth2., l'API ou le Resource Server RS qui fournit les informations au
Resource Owner n'a aucun moyen de savoir si l'utilisateur est toujours
connecté ou non. Ce qui pose problème parce qu'un client peut
continuer à récupérer un access token à partir du
refresh token alors que le Resource Owner RO est déconnecté, le
RS n'a aucun moyen de le savoir. En cas d'authorization code injection, ou
d'access token injection ou une autre attaque, l'attaquant peut accéder
aux ressources du RO donc usurper l'identité du Resource Owner sur un
service utilisant le protocole OAuth2. OpenID Connect est une couche qui
vient s'ajouter à OAUTH 2.0 en mettant à disposition en plus de
l'access token et du refresh token, un ID Token qui va porter l'identité
de la personne connectée. OIDC a pour but d'identifier la personne
derrière le navigateur ou l'application connecté à un
service. La norme OIDC a été conçue spécifiquement
pour l'authentification des utilisateurs.
2.1.7. SAML pour Security Assertion Markup
Language
C'est un protocole ouvert et standardisé basé
sur XML, il permet d'échanger des infos d'authentification et
d'autorisation entre des entités ou domaines de sécurité.
Il gère le processus d'échange entre :
Service Provider(SP) qui protège
l'accès aux ressources demandées (site web, application, etc) en
appliquant une politique de sécurité.
Identity Provider(IdP) qui répond
à la demande du SP, il est chargé d'authentifier l'utilisateur et
de forger les infos associées à l'identité et qui sont
demandées par le SP.
2.1.8. SSO pour Single
Sign On / Single Sign Out
Dans ce modèle l'utilisateur n'a besoin de
s'authentifier qu'une fois (d'où le nom de SSO) et il est de facto
authentifié auprès des autres fournisseurs de service. On utilise
des credentials unique quelque soit le service demandé au sein du
domaine d'identité. Ceci est aussi valable pour la déconnexion
(Single Sign Out)
2.1.9.
Fédération des identités
C'est un modèle de gestion de données dans
lequel les SP(Service Provider) sont groupés pour former une
fédération. Chacun des SP sera donc en mesure de
reconnaître les identifiants provenant d'autres SP de la même
fédération. La fédération donne aux utilisateurs
l'illusion d'utiliser qu'un seul identifiant (mais derrière, il
s'identifie auprès de chaque IdP). Chaque SP utilise son propre IdP mais
reconnaît les identités provenant d'autres SP
| 
