Difference between revisions of "VT2017 OAuth2"
| Line 51: | Line 51: | ||
Un client voulant acceder au données du Ressource Owner va contacter le serveur d'autorisation qui lui fournira un lien. Ce lien permettra au serveur d'autorisation de verifier l'identitée du Ressource Owner et envoyer (si le Ressource Owner accepte) un code d'autorisation au client. Le client peut alors échanger ce code avec le token d'accès qui lui permettra d'obtenir la ressource souhaitée du serveur de ressources. |
Un client voulant acceder au données du Ressource Owner va contacter le serveur d'autorisation qui lui fournira un lien. Ce lien permettra au serveur d'autorisation de verifier l'identitée du Ressource Owner et envoyer (si le Ressource Owner accepte) un code d'autorisation au client. Le client peut alors échanger ce code avec le token d'accès qui lui permettra d'obtenir la ressource souhaitée du serveur de ressources. |
||
| − | Le token d'accès ayant une durée de validité limitée il est possible d'obtenir un token de renouvellement |
+ | Le token d'accès ayant une durée de validité limitée il est possible d'obtenir un token de renouvellement au mêm moment que le token d'accès. |
[[File:OAuth code.png]] |
[[File:OAuth code.png]] |
||
| − | |||
===Autorisation implicite=== |
===Autorisation implicite=== |
||
| + | L'autorisation implicite est utilisé quand l'application se trouve chez le Ressource Owner (Application mobile, navigateur...). |
||
| − | |||
| − | Contrairement au mode précédent, l'autorisation implicite renvoi directement un token d'accès au client |
+ | Contrairement au mode précédent, l'autorisation implicite renvoi directement un token d'accès au client après l'authentification du Ressource Owner (en utilisant l'URL de redirection). |
[[File:OAuth2 Implicit.png]] |
[[File:OAuth2 Implicit.png]] |
||
===Autorisation via un mot de passe (Resource Owner Password Credentials Grant)=== |
===Autorisation via un mot de passe (Resource Owner Password Credentials Grant)=== |
||
| + | Ce type d'autorisation n'est utile que si le client et le service (serveur d'autorisation + serveur des ressources) ont une confiance totale (ex : Appartiennent à la même société). |
||
| + | En effet l'obtention d'un token d'accès se fait simplement à l'aide du nom d'utilisateur et de son mot de passe. |
||
| + | |||
[[File:OAuth2 password.png]] |
[[File:OAuth2 password.png]] |
||
===Autorisation serveur à serveur=== |
===Autorisation serveur à serveur=== |
||
| + | |||
[[File:OAuth2 client.png]] |
[[File:OAuth2 client.png]] |
||
Revision as of 23:43, 28 September 2017
Présentation
- Sujet : OAuth2
- Auteur : Ahmed Amine NASSIK
- Enseignants : Didier Donsez, Georges-Pierre Bonneau
Résumé
OAuth2 est un protocole d'autorisation permettant d'obtenir un accès limité à un compte utilisateur d'un service tel que Twitter Google ou Facebook. Ce protocole délègue l'authentification au service hébergeant le compte et permet a des applications tierces d’accéder de manière limitée au compte utilisateur. Les spécifications du protocole subissent toujours des ajouts et des modifications, ce qui ne l'empêche pas d’être déjà très utilisé.
Abstract
OAuth2 is an authorization protocol that allows limited access to a user's account of a service such as Twitter Google and Facebook. This protocol, delegates authentication to the service hosting the user's account and allows third party applications to access the user account. The protocol specifications still undergo changes, although it doesn't prevent it from being already widespread.
Mots-clés
- Protocole
- Authentification
- Autorisation
- Token d'accès
- API
Synthèse
Le protocole OAuth2 spécifie l'utilisation d'HTTPS pour les échanges entre client et serveur d'authentification. TBC...
Enregistrement du client(application)
Avant qu'une application puisse accéder aux données d'un serveur de ressources, il faut enregistrer l'application auprès du serveur d'authentification. Les données nécéssaires à l'enregistrement sont :
- Nom de l'application
- Site de l'application
- Redirect URLs : URL de redirection du client (après l'authentification du Ressource Owner)
Rôles
OAuth2 définit 4 rôles qui seront définis dans les parties suivantes.
Ressource Owner
Il s'agit de la personne autorisant le client à acceder aux données de son compte.
Client
Application qui accède au données du Ressource Owner.
Authorization Server
Serveur d'autorisation vérifiant l'identité de l'utilisateur et fournissant les token (jetons : chaîne de caractères) d'accès au client.
Ressource Server
Serveur hébergeant les données du compte du Ressource Owner.
Types d'autorisation
Cette partie detaille les 4 types d'autorisation défini par OAuth2. Le choix du mode d'autorisation dépend de la situation et de la nature du client.
Autorisation via un code
Un client voulant acceder au données du Ressource Owner va contacter le serveur d'autorisation qui lui fournira un lien. Ce lien permettra au serveur d'autorisation de verifier l'identitée du Ressource Owner et envoyer (si le Ressource Owner accepte) un code d'autorisation au client. Le client peut alors échanger ce code avec le token d'accès qui lui permettra d'obtenir la ressource souhaitée du serveur de ressources.
Le token d'accès ayant une durée de validité limitée il est possible d'obtenir un token de renouvellement au mêm moment que le token d'accès.
Autorisation implicite
L'autorisation implicite est utilisé quand l'application se trouve chez le Ressource Owner (Application mobile, navigateur...). Contrairement au mode précédent, l'autorisation implicite renvoi directement un token d'accès au client après l'authentification du Ressource Owner (en utilisant l'URL de redirection).
Autorisation via un mot de passe (Resource Owner Password Credentials Grant)
Ce type d'autorisation n'est utile que si le client et le service (serveur d'autorisation + serveur des ressources) ont une confiance totale (ex : Appartiennent à la même société). En effet l'obtention d'un token d'accès se fait simplement à l'aide du nom d'utilisateur et de son mot de passe.
Autorisation serveur à serveur
