Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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).
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
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)
OAUTH 2.0 – Principe général d'accès à une ressource protégéeObtention d'un accord de l'utilisateur puis obtention d'un jeton d'accès
OAUTH 2.0 – Renouvellement d'un jeton d'accès expiré
OAUTH 2.0 – Flux de l'obtention d'accord par code (application Web)
OAUTH 2.0 – Exemples de demandes de jeton d'accès avec code d'autorisation ou assertion SAML
OAUTH 2.0 – Obtention d'accord implicite (application mobile ou JavaScript)
OAUTH 2.0 – Obtention d'accord par mot de passe utilisateur(applications de confiance)
OAUTH 2.0 – Accord par authentification du client(cas d'usage serveur à serveur)
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
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
Related Documents
