Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi parlez-vous ?
-
Upload
philippe-beraud -
Category
Technology
-
view
1.005 -
download
0
description
Transcript of Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi parlez-vous ?
Sécurité
Vous avez dit protocoles Web d’authentification et
d’autorisation! De quoi parlez-vous ?Philippe Beraud
Jean-Yves GrassetDirection Technique | Microsoft France
#mstechdaysSécurité
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 !
Donnez votre avis !
Anatomie d’une application moderne
Reposent sur une grande variété de langages / plates-formes /appareils
Navigateur
App native
App serveur
Application Web
API (service)
Web
Reposent sur une grande variété de langages / plates-formes
Basic, SAML 2.0, WS-Fed, OpenID Connect
(WS-Trust,) OAuth 2.0
OAuth 2.0
OAuth 2.0
Des protocoles standard fondés sur HTTP pour une portée maximale
Sécurité#mstechdays
AUTHENTIFICATION BASIQUE HTTP
Pour commencer par le début…
#mstechdaysSécurité
• Protocole d’authentification défini dans le RFC 2617
• Fondé sur un Challenge / Réponse• Utilise le protocole HTTP pour l’échange des
messages
Vue d’ensemble de l’authentification basique
#mstechdaysSécurité
Envoyée par le navigateur (agent utilisateur)
Texte brut sur TCP
Comprend le verbe et la ressource
Requête HTTP
VerbeRessourceProtocole
#mstechdaysSécurité
Réponse HTTPCode de réponse
Entêtes
Corps
#mstechdaysSécurité
Le navigateur envoie une requête
Entête WWW-AuthenticateRenvoyée avec un 401Listes sur les méthodes d'authentification prises en charge
Entête AuthorizationMéthode d’authentification: BasicInformations d’identification: encodes en Base64
Authentification basique
#mstechdaysSécurité
Echanges pour l’authentificationRequête HTTP usuelle
Réponse HTTP avec le code 401, comprenant l’entête
WWW-Authenticate: Basic
Même requête HTTP, comprenant l’entête
Authorization: Basic <Cred>Réponse HTTP usuelle
1ère requête
client
L’utilisateur entre ses informations
d’identification
Requête HTTP usuelle, comprenant l’entête Authorization: Basic
<Cred>Réponse HTTP usuelle
2nde requête
client
Client (Navigateur)
Serveur Web
Sécurité#mstechdays
OASIS SAML 2.0
#mstechdaysSécurité
Paquet d’information sur une identité
Synonyme de "jeton (de sécurité)"
Fondé sur XML
Se compose de déclarations :Déclarations d’authentificationDéclarations d’attributDéclarations de décision d’autorisation
SAML 2.0 - Assertions
#mstechdaysSécurité
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
Protocoles SAML 2.0Authentication RequestArtifact ResolutionSingle LogoutAssertion Query and RequestName Identifier ManagementName Identifier Mapping
SAML 2.0 - Protocoles
#mstechdaysSécurité
Associent un message de protocole avec un protocole de transport
ExemplesLa liaison POST HTTP spécifie comment un message de protocole SAML est envoyé par les méthode POST HTTPLa liaison SOAP SAML spécifie comment un message de protocole SAML est envoyé avec SOAP 1.1
Liaisons SAML 2.0HTTP RedirectHTTP POSTHTTP ArtifactSAML SOAPReverse SOAPSAML URI
SAML 2.0 - Liaisons
#mstechdaysSécurité
Décrit comment les assertions, les protocoles et les liaisons se combinent pour former un scénario
Exemple : Profil Web SSOAuthentication Request ProtocolLiaison Redirection HTTP au niveau fournisseur d’identité (IdP)Liaison POST HTTP au niveau fournisseur de service (SP)
Profils SAML 2.0Profils SSO• Web Browser SSO Profile• Enhanced Client or Proxy (ECP) Profile• Identity Provider Discovery Profile• Single Logout Profile• Name Identifier Management Profile
Artifact Resolution ProfileAssertion Query/Request ProfileName Identifier Mapping ProfileSAML Attribute Profiles • Basic Attribute Profile• X.500/LDAP Attribute Profile• UUID Attribute Profile• DCE PAC Attribute Profile• XACML Attribute Profile
SAML 2.0 - Profils
#mstechdaysSécurité
Envoie les données au serveur Web
Les données sont :Form-encodedDans le corps de la requête
Verbe POST
#mstechdaysSécurité
Maintiennent l’étatLe client retourne le cookie à chaque requête
Transmis en texte clairDoit être chiffrées par le serveur
Cookie Attributes NameDomain et Path (périmètre)ExpirationDrapeau sécurisé (envoi uniquement sur SSL/TLS)Drapeau HttpOnly
Cookies (témoins de connexion)Client
(Navigateur)Serveur
WebRequête HTTP usuelle
Réponse HTTP usuelle, comprenant la ligne d’entêteSet-cookie: <cookie>
1ère requête
client
Requête HTTP usuelle, comprenant la ligne d’entête
Cookie: <cookie>
Requête HTTP usuelle
2nde requête
client
#mstechdaysSécurité
Indique au navigateur où trouver une ressource
Code de réponse 302
L’entête Location indique la ressource
Redirection HTTP
#mstechdaysSécurité
Application Web
Emetteur SAML
Profil SAML Web SSO
Utilisateur
Confiance
Navigue
Est redirigé
TUne 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
S’authentifie
Sécurité#mstechdays
OASIS WS-FEDERATION
#mstechdaysSécurité
Relation avec SAML-PSimilaire au profil SAML Web SSO maisnon compatible• Messages de requête et de réponse différents• Pas de cas d’utilisation IdP-initiated• Pas de profil Assertion Query
WS-Federation – Profil de demandeur passif
Requête d’authentification SAML 2.0
Requête de jeton de sécurité WS-Federation
#mstechdaysSécurité
Simple Object Access Protocol
Utilisé par les clients pour invoquer des services Web SOAPMessage formaté en XMLPOSTé au service Web
SOAP<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <m:getCountries xmlns:m="AddressFinder"> <datasource xsi:type="xsd:string">TA.Address.EU</datasource> </m:getCountries> </SOAP-ENV:Body></SOAP-ENV:Envelope>
<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <n:getCountriesResponse xmlns:n="http://contoso.com/v2"> <Result href="#id0"/> </n:getCountriesResponse> <id0 id="id0" xsi:type="soapenc:Array" soapenc:arrayType="xsd:string[3]"> <i xsi:type="xsd:string">AN</i> <i xsi:type="xsd:string">AU</i> <i xsi:type="xsd:string">BE</i> </id0> </soap:Body></soap:Envelope>
Requête SOAP
Réponse SOAP
#mstechdaysSécurité
Clients SOAP
Le client demande un jetonUtilise WS-Trust comme spécificationRST = Request Security TokenRSTR = Request Security Token Response
Le client récupère la politique du service WebBasé sur WS-Policy
WS-Federation: Profil de demandeur actif
Secu
rity
Toke
n Re
spon
se
Secu
rity T
oken
Req
uest
#mstechdaysSécurité
Flux actif de fédération
Utilisateur
Confiance
Requête SOAP
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
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
Authentificateur
RST
RSTR
T
API (service)
Web
STS
Application client
Sécurité#mstechdays
IETF OAUTH 2.0
#mstechdaysSécurité
Scénario :Vous achetez quelque chose sur un site de e-CommerceVous voulez dire à vos amis sur Facebook que vous venez de l'acheter
Points à considérerSé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 e-Commerce
– Est-ce que le site de e-Commerce stocke les mots de passe en toute sécurité ?
Confiance :– 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 ?
Pourquoi OAuth 2.0 existe ?
#mstechdaysSécurité
Scénario :Vous trouverez une nouvelle super application Twitter dans le StoreVous téléchargez l'application et l’exécutezL'application a besoin de vos informations d'identification Twitter pour accéder à votre flux
Points à considérerSé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 :
– Comment savez-vous de l'application n’abusera de votre information Twitter ou gazouillera quelque chose à votre insu ?
Pourquoi OAuth 2.0 existe ?
#mstechdaysSécurité
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 passeVous voulez contrôler ce que l'application peut faireVous souhaitez révoquer les autorisations d’accès aux données d'une application plus tardVous souhaitez modifier votre mot de passe sans avoir à le mettre à jour dans toutes les applications
L’objectif d’OAuth 2.0
#mstechdaysSécurité
Un bref historiqueOAuth 1.0Défini en 2007Nécessité l'utilisation de signatures cryptographiquesRequis pour chaque appel d'APIDifficile d’accès pour un développeurCe qui contribue à la diminution de son adoptionPrend en compte uniquement le scenario Serveur à Serveur
OAuth 2.0Standardisé en octobre 2012L’absence de signatures cryptographiques le rend plus facile d’usagePas de rétrocompatibilité avec OAuth 1.0Adresse d'autres scénarios d'accès
OAuth WRAPPrésenté par Microsoft, Google, et Yahoo comme un complément temporaire à OAuthSuppression de la nécessité d’utiliser des signatures cryptographiquesIntroduction des jetons porteur (bearer tokens)Pas des mieux reçus par le fondateur d’OAuth
#mstechdaysSécurité
Le serveur de ressourcesHéberge la ressourceTypiquement un fournisseur d'API
Le propriétaire de la ressourcePossède la ressourceTypiquement un utilisateur de l’application
Le clientL’application invoquant des API pour effectuer des actions sur la ressource
Le serveur d’autorisationEmet le jeton d'accès utilisé par le client pour accéder à la ressourceAuthentifie le propriétaire de la ressourceObtient du propriétaire de la ressource un consentement d’accès
Les différents rôles
#mstechdaysSécurité
Pour la plupart des scénarios, le client doit être enregistré à l’avance au niveau du serveur d’autorisationAssure que le client est une entité connue et digne de confianceGénère un identifiant unique du clientEtablit un secret d’authentification entre le client et le serveur d’autorisation
Enregistrement du client
#mstechdaysSécurité
Ce que le client utilise pour accéder à la ressourceL’objectif principal est d'obtenir un jeton d'accès pour le client
Jeton porteur (bearer token)La possession du jeton prouve l’accèsSemblable à de l’argent liquide, l'identité du porteur n'est pas vérifiéeDoit être gardé secret
Envoyé dans chaque requête pour la ressourceTypiquement 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– Paramètre de la chaîne de requête (query string)– Paramètre du corps encodé (form-encoded)
Jeton d’accès
#mstechdaysSécurité
Les jetons d’accès ont des durées de vieLe client perd l’accès à la ressource lorsqu’il expireNécessite une interaction avec l'utilisateur pour en obtenir un nouveau
Le jeton d’actualisation procure un accès à long termeAucune durée de vieValide jusqu’à ce que l’utilisateur révoque l’accès pour le clientLe client le stocke
Comment les jetons d’actualisation sont utilisésRetourné avec le jeton d’accès depuis le serveur d’autorisation OAuth (optionnel)Le client demande un jeton d’accès en envoyant :
– Le jeton d’actualisation– ID client et secret
Jeton d’actualisation (refresh token)
#mstechdaysSécurité
Deux points de terminaison au niveau Serveur d’autorisationPoint 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 ClientPoint de terminaison de redirection
– Le client est à l’écoute pour le code d'autorisation– Utilisé dans le scénario Octroi d’un code d’autorisation
Points de terminaison
#mstechdaysSécurité
Flux Code d’autorisationApplications Web côté Serveur (par ex. Amazon accédant à Facebook en votre nom)
Flux impliciteUtilisé pour des applications Web côté client s’exécutant dans le navigateur (JavaScript)
Flux Mot de passe du propriétaire de la ressourceClients (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 clientLes clients qui peuvent utiliser des ressources indépendamment de l'autorisation du propriétaire de la ressource
Les 4 flux officiels
#mstechdaysSécurité
ScénarioLe client OAuth 2.0 est une application serveur WebUn accès à long terme est nécessaire pour la ressourceLe jeton d'accès ne doit pas être divulgué au navigateur
ExempleJacques veut partager un achat sur Amazon sur son journal FacebookRôle OAuth 2.0 :• Propriétaire de la ressource : Jacques• Client : Amazon• Serveur de ressources : Facebook• Ressource : journal Facebook de Jacques
Flux Code d’autorisation
#mstechdaysSécurité
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’autorisationclient_id : identificateur unique d’Amazon, enregistré avec Facebookredirect_uri : url d’Amazon vers laquelle le code d’autorisation est retournéscope : définit un droit d'accès sur Facebook qu’Amazon veutstate : 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
Etape 1 : Redirection vers le serveur d’autorisation
#mstechdaysSécurité
Requête HTTP pour le code d’autorisationRequêteGET https://www.facebook.com/dialog/oauth?response_type=code&client_id=202253513150354&redirect_uri=https%3A%2F%2Fwww.%2Eamazon%2Ecom%2Foauthcallback&scope=publish_stream&state=xyz
Entêtes de la requêteHost: www.facebook.com
#mstechdaysSécurité
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 Amazonstate : valeur de prévention CSRF dans la requête de code d’autorisation
Le code d'autorisation est exposé au navigateurLe code en lui-même de vous donne rienLe code doit être échangé avec le secret client pour un jeton d’accès
Etape 2 : Le client obtient un code d’autorisation
#mstechdaysSécurité
Réponse HTTP du serveur OAuth avec le code d’autorisationRéponse302 Found
Entêtes de la réponseLocation: https://www.amazon.com/oauthcallback?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
#mstechdaysSécurité
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 fluxcode : code d’autorisation précédemment reçu de Facebookredirect_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êteAuthentification basique – utilise l’entête Authorization dans la requêteParamètres de la requête – utilise les paramètres client_id et client_secret dans le corps du POST
Etape 3: Echange du code pour le jeton d’accès
#mstechdaysSécurité
Requête HTTP du client Web vers le serveur OAuth pour demander un jeton d’accèsRequêtePOST https://graph.facebook.com/oauth/access_token
Entêtes de la requêteContent-Type: application/x-www-form-urlencoded
Corps de la requêtegrant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fwww.%2Eamazon%2Ecom%2Foauthcallback
#mstechdaysSécurité
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 journaltoken_type : type de jeton, habituellement "Bearer"expires_in : durée de vie du jeton en secondesrefresh_token : jeton long-terme qui peut être utilisé pour acquérir un autre jeton d’accès plus tard
Etape 4 : Jeton d’accès donné à Amazon
#mstechdaysSécurité
Réponse HTTP du serveur OAuth vers le client WebCode de réponse200 OK
Corps de la réponse{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"Bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"}
#mstechdaysSécurité
Résumé du flux Code d’autorisation
Client
Serveur d’autorisation OAuth 2.0
Propriétaire de la ressource
1. Le client redirige le propriétaire de la ressource vers le serveur d'autorisation
2. Le propriétaire de la ressource s’authentifie et donne son consentement
3. Le serveur d’autorisation redirige le propriétaire de la ressource vers le client avec le code d’autorisation
4. Le client demande un jeton d'accès au serveur d'autorisation
5. Le serveur d’autorisation renvoie un jeton d’accès au Client
1 3
3
4
5
12
#mstechdaysSécurité
ScénarioLe client OAuth 2.0 est un composant client du navigateur (c.à.d. JavaScript ou Flash)Le navigateur est (fortement) digne de confianceL’accès à la ressource n'est que temporaire…
ExempleJacques utilise une application Web utilisant JavaScript dans le navigateur, et qui souhaite accéder à ses photos sur FacebookRô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
Flux implicite
#mstechdaysSécurité
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 impliciteclient_id : identifiant unique du client enregistré avec Facebookscope : définit un droit d’accès sur Facebook que le JavaScript veutredirect_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
Etape 1 : Redirection vers le serveur d’autorisation
#mstechdaysSécurité
Requête HTTP de la redirection JavaScriptRequêteGET https://www.facebook.com/dialog/oauth?response_type=token&client_id=s6BhdRkqt3&scope=read_photos&redirect_uri=https%3A%2F%2Fphotoapp%2Econtoso%2Ecom%2Foauthcallback.html
Entêtes de la requêteHost: www.facebook.com
#mstechdaysSécurité
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 Jacquestoken_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=3600Les fragments ne sont jamais retournés au serveur
Etape 2 : Jeton d’accès renvoyé
#mstechdaysSécurité
Réponse HTTP après la redirection JavaScriptCode de la réponse302 Found
Entêtes de la réponseLocation: https://photoapp.contoso.com/oauthcallback.html#access_token=2YotnFZFEjr1zCsicMWpAA&token_type=Bearer&expires_in=3600
#mstechdaysSécurité
Le composant serveur de l’application Photo retourne le JavaScript au navigateur de JacquesLe JavaScript a accès à l’URL complète, y compris le fragment
Le JavaScript analyse l’URL :Extrait le jeton d’accèsVérifie la date d’expiration
Le JavaScript utilise le jeton d’accès pour accéder aux photos de Jacques sur Facebook
Etape 3 : Le serveur renvoie l’analyseur (parser) JavaScript
#mstechdaysSécurité
Requête HTTP vers le rappel (callback) OAuthRequêteGET https://photoapp.contoso.com/oauthcallback.html
Entêtes de la requêteHost: photoapp.contoso.com
#mstechdaysSécurité
Réponse HTTP après la redirection vers le rappel OAuthCode la réponse200 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>
#mstechdaysSécurité
Client(Application Web)
Résumé du flux implicite
Propriétaire de la ressource
Composant JavaScript
(Navigateur)
Serveur d’autorisation OAuth 2.0
Composant Serveur Web
1. Le client redirige le propriétaire de la ressource vers le serveur d'autorisation
2. Le propriétaire de la ressource s’authentifie et donne son consentement
3. 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
4. Le composant serveur sur le client renvoie un script qui permet d’extraire le jeton d’accès à partir du fragment URL
2
1 4
4
1
3
3
#mstechdaysSécurité
ScénarioL’application client est digne d’une grande confiance
ExempleJacques utilise l’application officielle Facebook pour son smartphoneRôles OAuth 2.0 :• Propriétaire de la ressource : Jacques• Client : Application officielle Facebook• Serveur de ressources : Facebook• Ressource : Contenu Facebook de Jacques
Flux Mot de passe du propriétaire de la ressource
#mstechdaysSécurité
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 FacebookJacques fait confiance à l’application comme il s’agit de l’application officielleL’application Facebook ne stocke pas le nom d’utilisateur et le mot de passeLes informations d’identification de Jacques sont utilisées pour récupérer un jeton d’accès, et ensuite détruites
Etape 1 : Collecte des informations d’identification de l’utilisateur
#mstechdaysSécurité
L’application Facebook utilise les information d’identification de Jacques pour obtenir un jeton d’accèsElle envoie une requête POST au serveur d’autorisation OAuth de FacebookLa requête est envoyée au point de terminaison JetonElle 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)
Etape 2 : Echange des informations d’identification pour le jeton d’accès
#mstechdaysSécurité
Requête HTTP à partir du client mobile vers le serveur OAuthRequêtePOST https://www.facebook.com/oauth2/token
Entêtes de la requêteContent-Type: application/x-www-form-urlencoded
Corps de la requêtegrant_type=password&username=jacques%40outlook.fr&password=53cr3t&scope=alldata
#mstechdaysSécurité
Facebook répond à l’application Facebook avec un jeton d’accès au format JSON:access_token : jeton d’accès émis pour l’applicationtoken_type : type de jeton, habituellement "Bearer"expires_in : durée de vie du jeton en secondesrefresh_token : jeton long-terme qui peut être utilisé pour acquérir un autre jeton d’accès plus tard
Etape 3 : L’application Facebook obtient un jeton d’accès
#mstechdaysSécurité
Réponse HTTP du server OAuth vers le client mobileCode la réponse200 OK
Corps de la réponse{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"Bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"}
#mstechdaysSécurité
Résumé du flux Mot de passe du propriétaire de la ressource
Serveur d’autorisation OAuth 2.0
Propriétaire de la ressource
1. Le propriétaire de la ressource donne ses informations d’identification au Client
2. Le client utilise les informations d’identification pour demander un jeton d’accès au serveur d’autorisation
3. 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
Client
1
2
3
#mstechdaysSécurité
ScénarioLe client OAuth 2.0 nécessite des données spécifiques non-utilisateur, au nom du client plutôt qu’à celui l'utilisateurLe client OAuth 2.0 peut stocker en toute sécurité une clé utilisée pour l'authentification du client
ExempleJacques utilise une application Web d'entreprise qui lit son appartenance à un groupe depuis Windows Azure Active DirectoryRô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
Flux Informations d’identification du client
#mstechdaysSécurité
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 ADElle 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 fluxclient_id : identifiant unique du client tel qu’enregistré dans Windows Azure ADclient_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
Etape 1 : Obtention d’un jeton d’accès avec les informations d’identification du client
#mstechdaysSécurité
Requête HTTP du client vers le serveur OAuthRequêtePOST https://login.windows.net/contoso.com/oauth2/token?api-version=1.0
Entêtes de la requêteContent-Type: application/x-www-form-urlencoded
Corps de la requêtegrant_type=client_credentials&resource=https%3a%2f%2fgraph.windows.net&client_id=52752c8e-d73c-4f9a-a0f9-2d75607ecb8e&client_secret=qKDjII5%2FK8WyKj6sRo5a5vD6%2Bm74uk1A%2BpIlM%3D
#mstechdaysSécurité
Le serveur d’autorisation OAuth Windows Azure valide les identifiant et secret de l’application Web MétierUne 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
Etape 2 : Le client reçoit le jeton d’accès
#mstechdaysSécurité
Réponse HTTP du serveur OAuth vers le clientCode de la réponse200 OK
Corps de la réponse{ "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HV…"}
#mstechdaysSécurité
Résumé du flux Informations d’identification du client
Serveur d’autorisation OAuth 2.0Client
(Application Web)
1. Le client s’authentifie auprès du serveur d’autorisation et demande un jeton d’accès à partir du point de terminaison jeton
2. Le serveur d’autorisation vérifie les information d’identification du client, et si celles-ci sont valides, émet un jeton d’accès
1
2
#mstechdaysSécurité
Eran Hammer (l’éditeur de la spécification) est très négatif envers OAuth 2.0Opposé à 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-0-and-the-road-to-hell/
Le fondateur OAuth 2.0 a change d’avis…
#mstechdaysSécurité
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…
OAuth 2.0 et l’authentification
Sécurité#mstechdays
IETF OPENID CONNECT
#mstechdaysSécurité
Standard encore à l’état de projet
OAuth 2.0 n'est pas destiné à l'authentificationOpère hors d'une hypothèse; la personne donnant l’accès pourrait ne pas être l'utilisateurAucun jeton d'identité est fourni
Définit une couche d'identité sur le dessus d’OAuth 2.0Utilise deux flux OAuth 2.0 :• Flux Code d’Autorisation• Flux implicite
Ajoute un jeton d’identité dans l’échange OAuth 2.0Ajoute la possibilité de demander des revendications à l’aide d’un jeton d’accès OAuth 2.0
OpenID Connect
#mstechdaysSécurité
Utilisent JSON (RFC4627) pour représenter les revendicationsIETF Draft – actuellement en version 20
Conçus pour la compacitéFacilement transportables sur HTTP
Signature et chiffrementDéfinis dans l’entêteNon requis (peut être sécurisés par le transport)
Jetons Web JSON (JWT)
{"typ":"JWT", "alg":"HS256"}.{ "iss": "https://server.example.com", "sub": "24400320", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "auth_time": 1311280969, "acr": "urn:mace:incommon:iap:silver", "at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng"}
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9. eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
#mstechdaysSécurité
Utilisateur
Application Web
Fournisseur OpenID Connect
(OP)
Un client s’enregistre avec le fournisseur OpenID Connect (OP)L'utilisateur accède à l'application Web et initie une connexionL’application Web redirige l’utilisateur vers l’OPL’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’autorisationL’application Web envoie le code d’autorisation à l’OPL’OP crée le jeton d’identité [I] et le jeton d’accès et les retourne à l’application WebL’application Web vérifie le jeton d’identité
Authentification avec le flux Code d’autorisation
Enregistrement du client
Navigation et connexion
Requête AuthN
Authentification et consentement
Réponse AuthN
I
T
C
#mstechdaysSécurité
Fournisseur OpenID Connect
(OP)
Authentification avec le flux implicite
Enregistrement du client
Connexion
Requête AuthN
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 navigateurL’utilisateur initie une connexionLe client redirige l’utilisateur vers l’OPL’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 URLL’application Web répond avec le code client pour vérifier le jetonL’application Web vérifie le jeton d’identité
Authentification et consentement
Réponse AuthN T
Composant côté Client (Navigateur)
Navigation
I
Application Web
Utilisateur
#mstechdaysSécurité
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
Point de terminaison UserInfo
#mstechdaysSécurité
"Qui parle quoi ?" (nov. 2013)Catégorie Protocole AD FS Windows Azure AD
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émentationWeb vers Web
API OAuth 2.0, flux Code d’autorisation, client confidentiel
Non disponible Préversion*
OAuth 2.0, flux Informations d’authentification du client
Non disponible DisponibleServeur vers Web API OAuth 2.0 "Act As" Non disponible En cours
d’implémentation* Seuls les mono-locataires sont disponibles dans la préversion du flux Code d’autorisation OAuth 2.0 ; multi-locataire à venir
Disponible sur le Centre de téléchargement Microsoft
Leverage Windows Azure AD for modern business applications
Livres blancs et guides Etape-par-Etape
Pour aller plus loinactivdirectory.windowsazure.com/develop
Documentation Microsoft TechNethttp://go.microsoft.com/fwlink/p/?linkid=290967
Documentation Microsoft MSDNhttp://go.microsoft.com/fwlink/p/?linkid=290966
Blog d’équipe Microsoft Active Directoryhttp://blogs.msdn.com/b/active_directory_team_blog
© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
Digital is business