http://www.microsoft.com/france/mstechdays/programmes/2014/fiche-session.aspx?ID=3ac3a728-bdf8-4de9-bdd1-223d4d0d9911

2. Vous avez dit protocoles Web
d’authentification et
d’autorisation! De quoi parlezvous ?
Philippe Beraud
Jean-Yves Grasset
Direction Technique | Microsoft France
philippe.beraud@microsoft.com, @philberd
jyvesg@microsoft.com,
Sécurité

3. Donnez votre avis !
Depuis votre smartphone sur :
http://notes.mstechdays.fr
De nombreux lots à gagner toute les heures !!!
Claviers, souris et jeux Microsoft…
Merci de nous aider à améliorer les Techdays !
#mstechdays
Sécurité

4. Anatomie d’une application moderne

5. AUTHENTIFICATION BASIQUE HTTP
Pour commencer par le début…
#mstechdays
Sécurité

6. Vue d’ensemble de l’authentification
basique
• Protocole d’authentification défini dans le RFC 2617
• Fondé sur un Challenge / Réponse
• Utilise le protocole HTTP pour l’échange des messages
#mstechdays
Sécurité

7. Requête HTTP
Envoyée par le navigateur (agent utilisateur)
Texte brut sur ​TCP
Comprend le verbe et la ressource
#mstechdays
Sécurité

8. Réponse HTTP
#mstechdays
Sécurité

9. Authentification basique
Le navigateur envoie une
requête
Entête WWW-Authenticate
Renvoyée avec un 401
Listes sur les méthodes d'authentification prises
en charge
Entête Authorization
Méthode d’authentification: Basic
Informations d’identification: encodes en Base64
#mstechdays
Sécurité

10. Echanges pour l’authentification
WWW-Authenticate: Basic
Authorization: Basic <Cred>
Authorization: Basic <Cred>
#mstechdays
Sécurité

11. OASIS SAML 2.0
#mstechdays
Sécurité

12. SAML 2.0 - Assertions
Paquet d’information sur une
identité
Synonyme de "jeton (de
sécurité)"
Fondé sur XML
Se compose de déclarations
:
Déclarations d’authentification
Déclarations d’attribut
Déclarations de décision d’autorisation
#mstechdays
Sécurité

13. SAML 2.0 - Protocoles
Concerne le format des
éléments de requête et de
réponse
Sur la base de Requête /
Réponse
Définis dans la spécification
SAML Core
#mstechdays
Sécurité
Protocoles SAML 2.0
Authentication Request
Artifact Resolution
Single Logout
Assertion Query and Request
Name Identifier Management
Name Identifier Mapping

14. SAML 2.0 - Liaisons
Associent un message de
protocole avec un protocole
de transport
Exemples
La liaison POST HTTP spécifie comment un
message de protocole SAML est envoyé par les
méthode POST HTTP
La liaison SOAP SAML spécifie comment un
message de protocole SAML est envoyé avec
SOAP 1.1
#mstechdays
Sécurité
Liaisons SAML 2.0
HTTP Redirect
HTTP POST
HTTP Artifact
SAML SOAP
Reverse SOAP
SAML URI

15. SAML 2.0 - Profils
Décrit comment les
assertions, les protocoles et
les liaisons se combinent
pour former un scénario
Exemple : Profil Web SSO
Authentication Request Protocol
Liaison Redirection HTTP au niveau fournisseur
d’identité (IdP)
Liaison POST HTTP au niveau fournisseur de
service (SP)
#mstechdays
Sécurité
Profils SAML 2.0
Profils SSO
•
•
•
•
•
Web Browser SSO Profile
Enhanced Client or Proxy (ECP) Profile
Identity Provider Discovery Profile
Single Logout Profile
Name Identifier Management Profile
Artifact Resolution Profile
Assertion Query/Request Profile
Name Identifier Mapping Profile
SAML Attribute Profiles
•
•
•
•
•
Basic Attribute Profile
X.500/LDAP Attribute Profile
UUID Attribute Profile
DCE PAC Attribute Profile
XACML Attribute Profile

16. Verbe POST
Envoie les données au
serveur Web
Les données sont :
Form-encoded
Dans le corps de la requête
#mstechdays
Sécurité

17. Cookies (témoins de connexion)
Maintiennent l’état
Le client retourne le cookie à
chaque requête
Transmis en texte clair
Doit être chiffrées par le serveur
Set-cookie: <cookie>
Cookie Attributes Name
Domain et Path (périmètre)
Expiration
Drapeau sécurisé (envoi uniquement sur
SSL/TLS)
Drapeau HttpOnly
#mstechdays
Cookie: <cookie>
Sécurité

18. Redirection HTTP
Indique au navigateur où
trouver une ressource
Code de réponse 302
L’entête Location indique
la ressource
#mstechdays
Sécurité

19. Profil SAML Web SSO
Une relation de confiance est établie entre
l'application Web et l’émetteur SAML
L'utilisateur accède à l'application Web
L’application Web détecte que l'utilisateur n'est
pas authentifié et le redirige vers l'émetteur
SAML
L’utilisateur accède automatiquement à
l'émetteur SAML
L’utilisateur s'authentifie auprès de l’émetteur
SAML
L’émetteur SAML construit le jeton et le renvoie
à l'utilisateur
L’utilisateur POSTe le jeton à l’application Web
#mstechdays
Sécurité

20. OASIS WS-FEDERATION
#mstechdays
Sécurité

21. WS-Federation – Profil de demandeur
passif
Relation avec SAML-P
Similaire au profil SAML Web SSO mais
non compatible
•
•
•
Messages de requête et de réponse différents
Pas de cas d’utilisation IdP-initiated
Pas de profil Assertion Query
#mstechdays
Sécurité

22. SOAP
Simple Object Access
Protocol
Utilisé par les clients
pour invoquer des
services Web SOAP
Message formaté en XML
POSTé au service Web
#mstechdays
Sécurité

23. WS-Federation: Profil de demandeur actif
Clients SOAP
Le client demande un
jeton
Utilise WS-Trust comme spécification
RST = Request Security Token
RSTR = Request Security Token Response
Le client récupère la
politique du service Web
Basé sur WS-Policy
#mstechdays
Sécurité

24. Flux actif de fédération
Une relation de confiance est établie entre le
service Web et le service de jeton de sécurité
(STS)
L’utilisateur fournit un authentificateur à
l’application client
T
L’application client envoie un message RST au
STS, avec les informations d’identification de
l'utilisateur et l'identificateur du service Web
Le STS construit le jeton et le renvoie à
l’application client dans un message RSTR
L’application client inclut le jeton dans l’entête
de requête SOAP à destination du service Web
Le service Web vérifie le jeton et traite la
requête SOAP émise par l’application client
#mstechdays
Sécurité

25. IETF OAUTH 2.0
#mstechdays
Sécurité

26. Pourquoi OAuth 2.0 existe ?
Scénario :
Vous achetez quelque chose sur un site de e-Commerce
Vous voulez dire à vos amis sur Facebook que vous venez de l'acheter
Points à considérer
Sécurité :
–
–
–
Avez-vous confiance dans le site de e-Commerce pour conserver votre mot de passe Facebook ?
Est-ce que d’autres membres de votre famille dispose d’un accès à votre compte du site de eCommerce
Est-ce que le site de e-Commerce stocke les mots de passe en toute sécurité ?
Confiance :
–
–
#mstechdays
Avez-vous confiance de le site de e-Commerce pour n'afficher votre achat que sur votre mur ?
Comment savez-vous si le site de e-Commerce collecte des informations à partir de votre liste
d'amis ?
Sécurité

27. Pourquoi OAuth 2.0 existe ?
Scénario :
Vous trouverez une nouvelle super application Twitter dans le Store
Vous téléchargez l'application et l’exécutez
L'application a besoin de vos informations d'identification Twitter pour accéder à votre flux
Points à considérer
Sécurité :
–
–
Avez-vous suffisamment confiance en l'application pour lui donner votre mot de passe ?
Est-ce que l'application stocke vos informations d'identification en toute sécurité ?
Confiance :
–
#mstechdays
Comment savez-vous de l'application n’abusera de votre information Twitter ou gazouillera
quelque chose à votre insu ?
Sécurité

28. L’objectif d’OAuth 2.0
Permettre aux utilisateurs de fournir à une application un
accès limité à leurs données de manière fiable
Résoudre la problématique de stockage des informations
d’identification :
Vous n'avez pas assez confiance en l'application pour lui donner votre mot de passe
Vous voulez contrôler ce que l'application peut faire
Vous souhaitez révoquer les autorisations d’accès aux données d'une application plus tard
Vous souhaitez modifier votre mot de passe sans avoir à le mettre à jour dans toutes les applications
#mstechdays
Sécurité

29. Un bref historique
OAuth 1.0
OAuth WRAP
OAuth 2.0
Défini en 2007
Nécessité l'utilisation de signatures
cryptographiques
Requis pour chaque appel d'API
Difficile d’accès pour un
développeur
Ce qui contribue à la diminution de
son adoption
Prend en compte uniquement le
scenario Serveur à Serveur
Présenté par Microsoft, Google, et
Yahoo comme un complément
temporaire à OAuth
Suppression de la nécessité
d’utiliser des signatures
cryptographiques
Introduction des jetons porteur
(bearer tokens)
Pas des mieux reçus par le
fondateur d’OAuth
Standardisé en octobre 2012
L’absence de signatures
cryptographiques le rend plus
facile d’usage
Pas de rétrocompatibilité avec
OAuth 1.0
Adresse d'autres scénarios
d'accès
#mstechdays
Sécurité

30. Les différents rôles
Le serveur de ressources
Le client
Héberge la ressource
Typiquement un fournisseur d'API
L’application invoquant des API pour
effectuer des actions sur la ressource
Le propriétaire de la
ressource
Le serveur d’autorisation
Possède la ressource
Typiquement un utilisateur de l’application
#mstechdays
Sécurité
Emet le jeton d'accès utilisé par le client pour
accéder à la ressource
Authentifie le propriétaire de la ressource
Obtient du propriétaire de la ressource un
consentement d’accès

31. Enregistrement du client
Pour la plupart des scénarios, le client doit être enregistré à
l’avance au niveau du serveur d’autorisation
Assure que le client est une entité connue et digne de confiance
Génère un identifiant unique du client
Etablit un secret d’authentification entre le client et le serveur d’autorisation
#mstechdays
Sécurité

32. Jeton d’accès
Ce que le client utilise pour accéder à la ressource
L’objectif principal est d'obtenir un jeton d'accès pour le client
Jeton porteur (bearer token)
La possession du jeton prouve l’accès
Semblable à de l’argent liquide, l'identité du porteur n'est pas vérifiée
Doit être gardé secret
Envoyé dans chaque requête pour la ressource
Typiquement envoyé dans l’entête Authorization de la requête HTTP (préféré)
–
Rarement mis en cache ou journalisé par les serveurs proxy
D’autres méthodes sont supportées
–
–
#mstechdays
Paramètre de la chaîne de requête (query string)
Paramètre du corps encodé (form-encoded)
Sécurité

33. Jeton d’actualisation (refresh token)
Les jetons d’accès ont des durées de vie
Le client perd l’accès à la ressource lorsqu’il expire
Nécessite une interaction avec l'utilisateur pour en obtenir un nouveau
Le jeton d’actualisation procure un accès à long terme
Aucune durée de vie
Valide jusqu’à ce que l’utilisateur révoque l’accès pour le client
Le client le stocke
Comment les jetons d’actualisation sont utilisés
Retourné avec le jeton d’accès depuis le serveur d’autorisation OAuth (optionnel)
Le client demande un jeton d’accès en envoyant :
–
–
#mstechdays
Le jeton d’actualisation
ID client et secret
Sécurité

34. Points de terminaison
Deux points de terminaison au niveau Serveur d’autorisation
Point de terminaison Autorisation
–
–
Façade utilisateur final
L’utilisateur s’authentifie et donne son consentement
Point de terminaison Jeton
–
Utilisé pour obtenir un jeton d’accès
Un point de terminaison au niveau Client
Point de terminaison de redirection
–
–
#mstechdays
Le client est à l’écoute pour le code d'autorisation
Utilisé dans le scénario Octroi d’un code d’autorisation
Sécurité

35. Les 4 flux officiels
Flux Code d’autorisation
Applications Web côté Serveur (par ex. Amazon accédant à Facebook en votre nom)
Flux implicite
Utilisé pour des applications Web côté client s’exécutant dans le navigateur (JavaScript)
Flux Mot de passe du propriétaire de la ressource
Clients (dignes) de confiance, tels que les applications mobiles client obtenus à partir du
serveur de ressources (par ex. le client officiel Facebook)
Flux Informations d’identification du client
Les clients qui peuvent utiliser des ressources indépendamment de l'autorisation du
propriétaire de la ressource
#mstechdays
Sécurité

36. Flux Code d’autorisation
Scénario
Le client OAuth 2.0 est une application serveur Web
Un accès à long terme est nécessaire pour la ressource
Le jeton d'accès ne doit pas être divulgué au navigateur
Exemple
Jacques veut partager un achat sur ​Amazon sur son journal Facebook
Rôle OAuth 2.0 :
•
•
•
•
Propriétaire de la ressource : Jacques
Client : Amazon
Serveur de ressources : Facebook
Ressource : journal Facebook de Jacques
#mstechdays
Sécurité

37. Etape 1 : Redirection vers le serveur
d’autorisation
Amazon redirige Jacques vers le serveur d’autorisation
Facebook, avec les paramètres query string:
response_type : définit le flux OAuth – toujours "code" pour le flux Code d’autorisation
client_id : identificateur unique d’Amazon, enregistré avec Facebook
redirect_uri : url d’Amazon vers laquelle le code d’autorisation est retourné
scope : définit un droit d'accès sur Facebook qu’Amazon veut
state : valeur utilisée pour la prévention CSRF (Cross-Site Request Forgery)
Jacques s’authentifie sur Facebook et donne son
consentement au périmètre demandé par Amazon
#mstechdays
Sécurité

38. Requête HTTP pour le code d’autorisation
Requête
GET
https://www.facebook.com/dialog/oauth?response_type=code&client_id=202253
513150354&redirect_uri=https%3A%2F%2Fwww.%2Eamazon%2Ecom%2Foauthcallback&
scope=publish_stream&state=xyz
Entêtes de la requête
Host: www.facebook.com
#mstechdays
Sécurité

39. Etape 2 : Le client obtient un code d’autorisation
Facebook crée un code d'autorisation et redirige le
navigateur de Jacques vers le point OAuth d'Amazon
Paramètres de la chaîne de requête dans l’URL de
redirection :
code : code d’autorisation émis Facebook pour Amazon
state : valeur de prévention CSRF dans la requête de code d’autorisation
Le code d'autorisation est exposé au navigateur
Le code en lui-même de vous donne rien
Le code doit être échangé avec le secret client pour un jeton d’accès
#mstechdays
Sécurité

40. Réponse HTTP du serveur OAuth avec le code
d’autorisation
Réponse
302 Found
Entêtes de la réponse
Location: https://www.amazon.com/oauthcallback?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
#mstechdays
Sécurité

41. Etape 3: Echange du code pour le jeton d’accès
Amazon a besoin d'échanger le code d'autorisation pour un
jeton d'accès pour Facebook
Amazon envoie au serveur d'autorisation Facebook une
requête POST avec des paramètres de formulaire encodés
dans l’URL :
grant_type : définit le type d’octroi utilisé – toujours "authorization_code" pour ce flux
code : code d’autorisation précédemment reçu de Facebook
redirect_uri : même URI que dans la requête d’origine pour le code d’autorisation
Amazon envoie ses informations d’identification dans la
requête
Authentification basique – utilise l’entête Authorization dans la requête
#mstechdays
Paramètres de la requête – utilise les paramètres client_id et client_secret dans le corps
Sécurité

42. Requête HTTP du client Web vers le serveur
OAuth pour demander un jeton d’accès
Requête
POST https://graph.facebook.com/oauth/access_token
Entêtes de la requête
Content-Type: application/x-www-form-urlencoded
Corps de la requête
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fwww.%2Eamazon%2Ecom%2Foauthcallback
#mstechdays
Sécurité

43. Etape 4 : Jeton d’accès donné à Amazon
Facebook répond à Amazon avec un jeton d’accès au
format JSON :
access_token : jeton d’accès émis pour Amazon,
qui contient la permission de poster vers le journal
token_type : type de jeton, habituellement
"Bearer"
expires_in : durée de vie du jeton en secondes
refresh_token : jeton long-terme qui peut être
utilisé pour acquérir un autre jeton d’accès plus tard
#mstechdays
Sécurité

44. Réponse HTTP du serveur OAuth vers le client
Web
Code de réponse
200 OK
Corps de la réponse
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
#mstechdays
Sécurité

45. Résumé du flux Code d’autorisation
1.
2.
3.
4.
5.
Le client redirige le propriétaire
de la ressource vers le serveur
d'autorisation
Le propriétaire de la ressource
s’authentifie et donne son
consentement
Le serveur d’autorisation redirige
le propriétaire de la ressource
vers le client avec le code
d’autorisation
Le client demande un jeton
d'accès au serveur d'autorisation
Le serveur d’autorisation renvoie
un jeton d’accès au Client
#mstechdays
Sécurité

46. Flux implicite
Scénario
Le client OAuth 2.0 est un composant client du navigateur (c.à.d. JavaScript ou Flash)
Le navigateur est (fortement) digne de confiance
L’accès à la ressource n'est que temporaire…
Exemple
Jacques utilise une application Web utilisant JavaScript dans le navigateur, et qui souhaite accéder à
ses photos sur Facebook
Rôles OAuth 2.0 :
•
•
•
•
Propriétaire de la ressource : Jacques
Client : Application Web (Serveur et composants JavaScript)
Serveur de ressources : Facebook
Ressource : Photos Facebook de Jacques
#mstechdays
Sécurité

47. Etape 1 : Redirection vers le serveur
d’autorisation
L’application Photo JavaScript redirige Jacques vers le
serveur d’autorisation Facebook avec les paramètres de la
chaîne de requête :
response_type : définit le flux OAuth – toujours "token" pour le flux implicite
client_id : identifiant unique du client enregistré avec Facebook
scope : définit un droit d’accès sur Facebook que le JavaScript veut
redirect_uri : URL côté-serveur du client vers laquelle le navigateur est redirigé
Jacques s’authentifie sur Facebook et donne son
consentement pour le périmètre demandé par l’application
Photo JavaScript
#mstechdays
Sécurité

48. Requête HTTP de la redirection JavaScript
Requête
GET
https://www.facebook.com/dialog/oauth?response_type=token&client_id=s6BhdR
kqt3&scope=read_photos&redirect_uri=https%3A%2F%2Fphotoapp%2Econtoso%2Ecom
%2Foauthcallback.html
Entêtes de la requête
Host: www.facebook.com
#mstechdays
Sécurité

49. Etape 2 : Jeton d’accès renvoyé
Le serveur d’autorisation Facebook crée un jeton d’accès et
le renvoi avec une redirection 302 :
access_token : jeton d’accès émis pour l’application Photo, et qui a la permission de lire
les photos Facebook de Jacques
token_type : type de jeton, habituellement "Bearer"
expires_in : durée de vie du jeton en secondes
Jeton d’accès fourni dans un fragment URL :
https://photoapp.contoso.com/oauthcallback.html#access_token=abc123&token
_type=Bearer&expires_in=3600
Les fragments ne sont jamais retournés au serveur
#mstechdays
Sécurité

50. Réponse HTTP après la redirection JavaScript
Code de la réponse
302 Found
Entêtes de la réponse
Location:
https://photoapp.contoso.com/oauthcallback.html#access_token=2YotnFZFEjr1z
CsicMWpAA&token_type=Bearer&expires_in=3600
#mstechdays
Sécurité

51. Etape 3 : Le serveur renvoie l’analyseur (parser)
JavaScript
Le composant serveur de l’application Photo retourne le
JavaScript au navigateur de Jacques
Le JavaScript a accès à l’URL complète, y compris le fragment
Le JavaScript analyse l’URL :
Extrait le jeton d’accès
Vérifie la date d’expiration
Le JavaScript utilise le jeton d’accès pour accéder aux
photos de Jacques sur Facebook
#mstechdays
Sécurité

52. Requête HTTP vers le rappel (callback)
OAuth
Requête
GET https://photoapp.contoso.com/oauthcallback.html
Entêtes de la requête
Host: photoapp.contoso.com
#mstechdays
Sécurité

53. Réponse HTTP après la redirection vers le
rappel OAuth
Code la réponse
200 OK
Corps de la réponse
<script...>
var oauthParams = {};
var params = {};
var queryString = location.hash.substring(1);
var regex = /([^&=]+)=([^&]*)/g;
var m;
while (m = regex.exec(queryString))
{
oauthParams[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}
...
</script>
#mstechdays
Sécurité

54. Résumé du flux implicite
1.
2.
3.
4.
Le client redirige le propriétaire
de la ressource vers le serveur
d'autorisation
Le propriétaire de la ressource
s’authentifie et donne son
consentement
Le serveur d’autorisation redirige
le propriétaire de la ressource
vers le composant serveur du
client avec le jeton d’accès dans
un fragment URL
Le composant serveur sur le
client renvoie un script qui
permet d’extraire le jeton
d’accès à partir du fragment
URL
#mstechdays
Sécurité

55. Flux Mot de passe du propriétaire de la
ressource
Scénario
L’application client est digne d’une grande confiance
Exemple
Jacques utilise l’application officielle Facebook pour son smartphone
Rôles OAuth 2.0 :
•
•
•
•
Propriétaire de la ressource : Jacques
Client : Application officielle Facebook
Serveur de ressources : Facebook
Ressource : Contenu Facebook de Jacques
#mstechdays
Sécurité

56. Etape 1 : Collecte des informations
d’identification de l’utilisateur
Jacques installe l’application Facebook sur son smartphone
et l’exécute pour la première fois
L’application Facebook demande à Jacques ses nom
d’utilisateur et mot de passe Facebook
Jacques fait confiance à l’application comme il s’agit de l’application officielle
L’application Facebook ne stocke pas le nom d’utilisateur et le mot de passe
Les informations d’identification de Jacques sont utilisées pour récupérer un jeton d’accès,
et ensuite détruites
#mstechdays
Sécurité

57. Etape 2 : Echange des informations
d’identification pour le jeton d’accès
L’application Facebook utilise les information d’identification
de Jacques pour obtenir un jeton d’accès
Elle envoie une requête POST au serveur d’autorisation
OAuth de Facebook
La requête est envoyée au point de terminaison Jeton
Elle comprend les paramètres de formulaire encodées dans l’URL :
–
–
–
–
grant_type : définit le type d’octroi utilisé – toujours "password" pour ce flux
scope : définit un droit d’accès sur Facebook que l’application veut
username : nom d’utilisateur Facebook de Jacques
password : mot de passe Facebook de jacques
Les client_id and client_secret peuvent optionnellement être envoyés s’il s’agit d’un client
confidentiel (pas dans cet exemple)
#mstechdays
Sécurité

58. Requête HTTP à partir du client mobile vers le
serveur OAuth
Requête
POST https://www.facebook.com/oauth2/token
Entêtes de la requête
Content-Type: application/x-www-form-urlencoded
Corps de la requête
grant_type=password&username=jacques%40outlook.fr&password=53cr3t&scope=al
ldata
#mstechdays
Sécurité

59. Etape 3 : L’application Facebook obtient un jeton
d’accès
Facebook répond à l’application Facebook avec un jeton
d’accès au format JSON:
access_token : jeton d’accès émis pour l’application
token_type : type de jeton, habituellement
"Bearer"
expires_in : durée de vie du jeton en secondes
refresh_token : jeton long-terme qui peut être
utilisé pour acquérir un autre jeton d’accès plus tard
#mstechdays
Sécurité

60. Réponse HTTP du server OAuth vers le client
mobile
Code la réponse
200 OK
Corps de la réponse
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
#mstechdays
Sécurité

61. Résumé du flux Mot de passe du propriétaire de
la ressource
1.
2.
3.
Le propriétaire de la ressource donne
ses informations d’identification au
Client
Le client utilise les informations
d’identification pour demander un
jeton d’accès au serveur d’autorisation
Le serveur d’autorisation procède à
une authentification, valide les
informations d’identification du
propriétaire de la ressource et
retourne un jeton d’accès
#mstechdays
Sécurité

62. Flux Informations d’identification du client
Scénario
Le client OAuth 2.0 nécessite des données spécifiques non-utilisateur, au nom du client plutôt qu’à celui
l'utilisateur
Le client OAuth 2.0 peut stocker en toute sécurité une clé utilisée pour l'authentification du client
Exemple
Jacques utilise une application Web d'entreprise qui lit son appartenance à un groupe depuis Windows
Azure Active Directory
Rôles OAuth 2.0 :
•
•
•
•
Propriétaire de la ressource : John
Client : Application Web Métier
Serveur de ressources: Windows Azure AD
Ressource : Liste des groupes dont Jacques est membre
#mstechdays
Sécurité

63. Etape 1 : Obtention d’un jeton d’accès avec les
informations d’identification du client
L’application Web Métier utilise ses information
d’identification pour demander un jeton d’accès au serveur
d’autorisation OAuth de Windows Azure AD
Elle envoie une requête POST au point de terminaison
OAuth de Windows Azure AD avec :
grant_type : type d’octroi OAuth utilisé – Toujours "client_credentials" pour ce flux
client_id : identifiant unique du client tel qu’enregistré dans Windows Azure AD
client_secret : secret partagé du client tel qu’obtenu dans Windows Azure AD lors de
l’inscription de l’application
– Les informations d’identification du client peuvent également être envoyées avec
l’entête Authorization, mais cela n’est pas pris en charge par Windows Azure AD
#mstechdays
Sécurité

64. Requête HTTP du client vers le serveur OAuth
Requête
POST https://login.windows.net/contoso.com/oauth2/token?api-version=1.0
Entêtes de la requête
Content-Type: application/x-www-form-urlencoded
Corps de la requête
grant_type=client_credentials&resource=https%3a%2f%2fgraph.windows.net&cli
ent_id=52752c8e-d73c-4f9a-a0f92d75607ecb8e&client_secret=qKDjII5%2FK8WyKj6sRo5a5vD6%2Bm74uk1A%2BpIlM%3D
#mstechdays
Sécurité

65. Etape 2 : Le client reçoit le jeton d’accès
Le serveur d’autorisation OAuth Windows Azure valide les
identifiant et secret de l’application Web Métier
Une réponse HTTP 200 est retournée à l’application Web
Métier avec le jeton d’accès au format JSON :
access_token : jeton d’accès émis pour
l’application
token_type : type de jeton, habituellement
"Bearer"
expires_in : durée de vie du jeton en secondes
#mstechdays
Sécurité

66. Réponse HTTP du serveur OAuth vers le client
Code de la réponse
200 OK
Corps de la réponse
{
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HV…"
}
#mstechdays
Sécurité

67. Résumé du flux Informations d’identification du
client
1.
2.
Le client s’authentifie auprès du
serveur d’autorisation et demande
un jeton d’accès à partir du point de
terminaison jeton
Le serveur d’autorisation vérifie les
information d’identification du
client, et si celles-ci sont
valides, émet un jeton d’accès
#mstechdays
Sécurité

68. Le fondateur OAuth 2.0 a change d’avis…
Eran Hammer (l’éditeur de la spécification) est très négatif
envers OAuth 2.0
Opposé à la suppression de l’exigence de signature numérique http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/
Frustré par le processus de standardisation - http://hueniverse.com/2012/07/oauth-2-0and-the-road-to-hell/
#mstechdays
Sécurité

69. OAuth 2.0 et l’authentification
OAuth 2.0, en tant que protocole, n’est pas conçu pour
résoudre le problème de l’authentification
OAuth 2.0 réalise une authentification lors de son processus
d'émission de jeton d'accès
Quel protocole d’authentification utilise OAuth 2.0 ?
Ceci est complètement à la discrétion du serveur d’autorisation OAuth…
#mstechdays
Sécurité

70. IETF OPENID CONNECT
#mstechdays
Sécurité

71. OpenID Connect
Standard encore à l’état de projet
OAuth 2.0 n'est pas destiné à l'authentification
Opère hors d'une hypothèse; la personne donnant l’accès pourrait ne pas être l'utilisateur
Aucun jeton d'identité est fourni
Définit une couche d'identité sur le dessus d’OAuth 2.0
Utilise deux flux OAuth 2.0 :
•
•
Flux Code d’Autorisation
Flux implicite
Ajoute un jeton d’identité dans l’échange OAuth 2.0
Ajoute la possibilité de demander des revendications à l’aide d’un jeton d’accès OAuth 2.0
#mstechdays
Sécurité

72. Jetons Web JSON (JWT)
Utilisent JSON (RFC4627) pour représenter les
revendications
IETF Draft – actuellement en version 20
Conçus pour la compacité
Facilement transportables sur HTTP
Signature et chiffrement
Définis dans l’entête
Non requis (peut être sécurisés par le transport)
#mstechdays
Sécurité

73. Authentification avec le flux Code d’autorisation
Un client s’enregistre avec le fournisseur OpenID
Connect (OP)
L'utilisateur accède à l'application Web et initie une
connexion
L’application Web redirige l’utilisateur vers l’OP
L’utilisateur s’authentifie auprès de l’OP et donne
son consentement afin que l’application Web
utilise son identité
L’OP construit un code d’autorisation [C]
L’OP redirige l’utilisateur vers l’application Web
avec le code d’autorisation
L’application Web envoie le code d’autorisation à
l’OP
L’OP crée le jeton d’identité [I] et le jeton d’accès et
les retourne à l’application Web
L’application Web vérifie le jeton d’identité
#mstechdays
Sécurité


74. Authentification avec le flux implicite
Un client s’enregistre avec le fournisseur
OpenID Connect (OP)
L'utilisateur accède à l'application Web et reçoit
un script client qui s’exécute dans le navigateur
L’utilisateur initie une connexion
Le client redirige l’utilisateur vers l’OP
L’utilisateur s’authentifie auprès de l’OP et
donne son consentement afin que l’application
Web utilise son identité
L’OP crée le jeton d’identité [I] et le jeton
d’accès [T]
L’OP redirige l’utilisateur vers l’application Web
avec les jetons dans un fragment URL
L’application Web répond avec le code client
pour vérifier le jeton
L’application Web vérifie le jeton d’identité
#mstechdays
Sécurité


75. Point de terminaison UserInfo
Retourne des revendications
supplémentaires sur un
utilisateur
Point de terminaison de type
REST
Authentification avec jeton
d'accès reçu d’un fournisseur
OpenID Connect
Réponse retournée en JSON
#mstechdays
Sécurité

76. "Qui parle quoi ?" (nov. 2013)
App native
OAuth 2.0, flux Code d’autorisation,
client public
AD FS 3.0
Préversion*
App Web
WS-Federation
AD FS 2.0+
Disponible
SAML 2.0
AD FS 2.0+
Disponible
OpenID Connect
Non disponible
En cours
d’implémentation
OAuth 2.0, flux Code d’autorisation,
client confidentiel
Non disponible
Préversion*
Non disponible
Disponible
Non disponible
En cours
d’implémentation
Web vers Web
API
OAuth 2.0, flux Informations
Serveur vers Web d’authentification du client
API
OAuth 2.0 "Act As"
#mstechdays
Sécurité

77. Livres blancs et guides Etape-par-Etape
Leverage Windows Azure AD for
modern business applications

78. Pour aller plus loin
activdirectory.windowsazure.com/develop
Documentation Microsoft TechNet
http://go.microsoft.com/fwlink/p/?linkid=290967
Documentation Microsoft MSDN
http://go.microsoft.com/fwlink/p/?linkid=290966
Blog d’équipe Microsoft Active Directory
http://blogs.msdn.com/b/active_directory_team_blog

79. Digital is
business