L’unification de l’identité en ligne est le processus par lequel, nous pouvons utiliser notre profile déjà existant sur un site (par exemple Facebook ou Google) pour nous authentifier sur un autre site. Par exemple Netvibes offre la possibilité aux usagers de se connecter via un de leurs comptes; Facebook, Twitter ou Google+.
Ce processus d’authentification unique (SSO en anglais) est réalisée avec le protocole OAuth, le standard SAML ou par la couche d’identification basée sur OAuth 2.0.
La différence entre OAuth 2.0 et OpenID Connect
La première chose à comprendre à propos d’OAuth 2.0 est qu’il s’agit d’un cadre d’autorisation, pas d’un protocole d’authentification. OAuth peut être utilisé pour résoudre un éventail de cas d’utilisation autres que la définition d’un flux de connexion Web ou mobile. OpenID Connect permet à la fois la validation et l’authentification . La grande différence entre OpenID Connect et OAuth 2.0 est le id_token. Il n’y a pas id_token défini dans OAuth 2.0, car id_token est spécifique à l’authentification fédérée. Id_token fournit une couche supplémentaire de sécurité aux transactions:
- Il contient un nonce, qui est envoyé par le client et permet de valider l’intégrité de la réponse;
- Il contient un hachage du jeton d’accès;
- Il contient éventuellement un hachage du code.
OAuth2 a été laissé générique afin qu’il puisse être appliqué à de nombreuses exigences d’autorisation, comme la gestion des accès API, la publication sur le mur de quelqu’un et l’utilisation des services IOT (internet des objects). OAuth 2.0 peut donc être utilisé pour beaucoup de tâches intéressantes, dont l’authentification des personnes.
La différence entre SAML et OpenID Connect
Dans SAML, l’utilisateur est redirigé du site Web vers le « IDP » (Identity Provider) alors que dans OpenID Connect, il est redirigé depuis le site Web (ou l’application mobile) vers le «OP» (OpenID Provider). Dans les deux cas, l’IDP / OP contrôle la connexion pour éviter d’exposer des secrets (comme des mots de passe) sur le site ou l’application.
Dans SAML, nous avons un « SP » (fournisseur de services – toujours un site Web) alors qu’OpenID Connect utilise un « RP » (Relying Party-soit un site Web ou une application mobile). Le RP est également fréquemment appelé le «client» car il étend un client OAuth 2.0.
Dans SAML, il existe une « assertion » – un document XML signé avec les informations sujet (authentifié), les attributs (informations sur la personne), l’émetteur (qui a émis l’assertion) et d’autres informations sur l’événement d’authentification. L’équivalent dans OpenID Connect est le id_token. C’est un document JSON signé qui contient l’objet, l’émetteur et les informations d’authentification.
Une grande différence entre Connect et SAML est l’utilisation du « canal avant » au lieu du « canal arrière ». Le canal frontal est le navigateur. Le canal arrière est la communication directe entre le site Web et l’IDP. Bien que SAML définisse les mécanismes de canal arrière, ils sont rarement utilisés dans la pratique. La manière la plus courante que SAML envoie la requête XML et la réponse XML (assertion) est via le navigateur. La plupart des sites SAML utilisent la fonction « POST Binding » pour envoyer la réponse. Dans ce scénario, le navigateur reçoit un formulaire HTML de l’IDP avec la réponse XML en tant que paramètre de formulaire. Il y a du JavaScript dans le formulaire pour le renvoyer automatiquement au SP. C’est une astuce car le SP et l’IDP n’ont pas besoin de connectivité réseau: le navigateur agit comme un intermédiaire!
Connect définit un mécanisme similaire (« Form Post Response Mode ») mais contrairement à SAML, son utilisation est plus l’exception que la règle. Les deux Connect et SAML (fréquemment) utilisent quelque chose comme le « Redirect Binding » pour envoyer la demande. C’est ici que les paramètres d’URL sont utilisés pour envoyer le XML. Cela tire également parti du navigateur.
Connect utilise normalement le canal arrière (un appel direct du RP vers l’OP) pour récupérer cette information. Les attributs (ou « revendications d’utilisateur » dans le jargon OpenID) sont disponibles pour le client en appelant le point de terminaison user_info (une API REST JSON). Cependant, comme il s’agit d’OAuth 2.0, le client a besoin d’un jeton pour appeler cette API. Et conformément à la structure OAuth 2.0, le jeton est également obtenu en utilisant le canal de retour à partir du point de terminaison de jeton de l’OP.
SAML, OAuth 2.0 ou OpenID Connect
En résumé, voici les cas où il est plus pertinent d’utiliser chacun d’eux;
- Pour une application mobile, c’est mieux d’utiliser OpenID Connect,
- Pour une application qui prend déjà en charge SAML, utiliser SAML
- Pour une nouvelle application, c’est mieux utilisez OpenID Connect
- Pour protéger des API ou pour créer une passerelle API, c’est mieux d’utiliser OAuth 2.0 ou le protocole UMA (User Managed Access).
Source; https://www.gluu.org/resources/documents/articles/oauth-vs-saml-vs-openid-connect/
Nouveautés technologiques 