Une présentation de notre directeur technique sur Oauth et OpenID

1. (
Décembre 2014
Cyril Grosjean
cgrosjean@janua.fr
Présentation OAUTH &
OpenID Connect

2. Pourquoi OAUTH - A quoi cela sert-il ?
- Donner à une application quelconque l'accès à certaines informations appartenant
à l'utilisateur, et hébergées sur un serveur Web quelconque :
- Avec le consentement de l'utilisateur, et la possibilité de révoquer l'application
- Sans avoir à divulguer à l'application son mot de passe sur le serveur Web
- de façon simple (par jetons opaques à usage multiple), en une ou 2 requêtes
- de façon standardisée et sécurisée (HTTPS, permissions (scope), anti-rejeu de jeton,
authentification du client, consentement de l'utilisateur, flux ne passant pas forcément
par le navigateur)
- protocole ouvert aux extensions, ce qui a permis par exemple l'utilisation d'assertions
SAML pour obtenir un jeton d'accès ou authentifier un client, ou l'extension à OpenID
Connect

3. OAUTH - OpenID Connect : Terminologie
- owner : propriétaire des informations (ressources). Généralement un utilisateur mais
pas forcément.
- resource : information / donnée protégée à laquelle on veut donner un accès contrôlé.
- authorization server ou OAUTH/OpenID provider: serveur chargé d'authentifier
l'utilisateur, de lui demander son consentement et de délivrer les jetons d'accès.
- resource server : serveur hébergeant les données protégées. En général différent du
serveur d'autorisation OAUTH sauf dans le cas d'OpenID Connect où l'OpenID
Provider joue aussi le rôle de serveur de ressources avec le point d'entrée "UserInfo".
- client / relying party: tout type d'application qui demande un accès à des données. Par
exemple, une application hébergée sur un serveur, un poste de travail, une application
native sur mobile ou avec une partie locale et une partie hébergée (Ajax, Javascript).

4. OAUTH 1.0 / OAUTH 2.0
- OAUTH 1.0 obsolète
- OAUTH 2.0 généralisé avec des différences d'implémentations d'où l'émergence d'une
surcouche visant à simplifier l'interaction avec différents types de serveur OAUTH 2 :
OAuth.io
- pas d'expiration / expiration des jetons (mais possibilité de les renouveler)
- pas de notion de scope / apparition du scope (ce à quoi un jeton donne droit)
- signature des requêtes (problèmes d'inter-opérabilités) / utilisation d'HTTPS à la place
- pas de serveur d'autorisation / serveur d'autorisation externe

5. OAUTH 2.0 – Caractéristiques principales
- 4 façons d'obtenir l'accord de l'utilisateur et des extensions possibles (SAML)
- 2 points d'entrées (autorisation, jeton d'accès), UserInfo en plus pour OpenID Connect
- 2 types de clients: privés / publiques
- 3 types d'application
- applications dites privées (sur un serveur Web sécurisé)
- applications dites publiques (qui s'exécute dans un navigateur, le code de l'application
ayant été téléchargé au préalable sur un serveur)
- applications publiques natives (sur PC ou mobile par exemple)

6. OAUTH 2.0 – Principe général d'accès à une ressource protégée
Obtention d'un accord de l'utilisateur puis obtention d'un jeton d'accès

7. OAUTH 2.0 – Renouvellement d'un jeton d'accès expiré

8. OAUTH 2.0 – Flux de l'obtention d'accord par code (application Web)

9. OAUTH 2.0 – Exemples de demandes de jeton d'accès
avec code d'autorisation ou assertion SAML

10. OAUTH 2.0 – Obtention d'accord implicite (application mobile ou JavaScript)

11. OAUTH 2.0 – Obtention d'accord par mot de passe utilisateur
(applications de confiance)

12. OAUTH 2.0 – Accord par authentification du client
(cas d'usage serveur à serveur)

13. OpenID Connect : extension d'OAUTH 2.0
- Support des différents types de consentement, autorisation pour accès déconnecté
- Le serveur OpenID délivre un "ID Token" en plus de l' "Access Token"
- Nouveau types de flux : flux hybride et redirection à partir d'une application externe

14. OpenID Connect : autres caractéristiques
- Nouveaux services / points d'entrée qui se comportent comme des ressources OAUTH
- UserInfo Endpoint : permet d'obtenir des informations particulières (claims) sur un
utilisateur, pas forcément présentes dans l' "ID Token"
- Dynamic Client Registration 1.0 : permet de ne pas avoir à déclarer au préalable
le client OpenID Connect auprès du serveur
- OpenID Connect Discovery 1.0 : permet de connaître les caractéristiques d'un serveur
OpenID Connect
- OpenID Connect Session Management 1.0 : permet de consulter les sessions et de les
fermer

15. Décembre 2014
Cyril Grosjean
cgrosjean@janua.fr
Merci de votre attention,
Avez-vous des questions ?