La Grande Famille OAuth 2.0
-
Upload
guillaume-sauthier -
Category
Internet
-
view
110 -
download
0
Transcript of La Grande Famille OAuth 2.0
La Grande Famille OAuth 2.0Comment partager ses ressources de manière sécurisée sur Internet
Guillaume Sauthier @sauthieg
Agenda
Pourquoi ?
OAuth 2.0, les bases
OpenId Connect, une application d’OAuth 2.0
UMA, ca se complique
Pourquoi ?un nouveau standard
L’existantSingle Sign-On propriétaire
Habituellement basé sur des cookies (same origin policy)
Cross-Domain SSO (form auto-submit)
Fédération SAML
Standard OASIS
Nativement cross-domain
Les Service Providers (SP) délèguent l’authentification à l’Identity Provider (IdP)
Tout ca marche bien, mais …Single Sign-On propriétaire est … propriétaire
Intéropérabilité minimale
Couplage fort avec le fournisseur d’identité
Fédération SAML est … compliquée
Mise en oeuvre difficile
Pas très mobile-friendly
Qui aime encore le XML ?
Les besoins modernesStandard endossé par l’industrie
Facilité d’utilisation
Application ubiquitaires (web, mobile, desktop, …)
Risques limités
Ne pas partager ses credentials
Contrôle sur les autorisations déléguées (révocation, …)
Implémentation du consommateur relativement simple
OAuth 2.0les bases, les flows, la PoP
Bonjour OAuth 2.0Standard IETF (RFC 6749)
Utilise du JSON
Basé sur des tokens
Access Token, Refresh Token
Consentement
Différents flows pour acquérir son token
Client Resource Server
Authz Server
autorisation scope!
vérification scope?
accès
Les flows de basepassword
Le plus direct, le moins sécurisé
Expose les crédentials de l’utilisateur
implicit
Pour les applications mobiles, applications JS “one-page”
Sécurité du token non garantie, pas de refresh token
client_credentials
Lorsque l’application a ses propres credentials
authorization code
Pour les applications web server-side
authorization codepas à pas
User (resource owner)
User-agent (web browser)
Auth Server
(as)
Application (client)
1. User authorization request
User (resource owner)
User-agent (web browser)
Auth Server
(as)
Application (client)
2. User authorizes application
click
User (resource owner)
User-agent (web browser)
Auth Server
(as)
Application (client)
3. Authorization code grant
HTTP/1.1 302 Redirect
Location: http://openig.example.com:8080/id_token/openid/callback?code=1234&state=xxxx
User (resource owner)
User-agent (web browser)
Auth Server
(as)
Application (client)
4. Access Token Request
POST https://openam.example.com:8443/openam/oauth2/access_token Content-Type: application/x-www-form-urlencoded Authorization: Basic base64(client_id:client_secret)
grant_type=authorization_code& code=1234& redirect_uri=<redirect_uri>
User (resource owner)
User-agent (web browser)
Auth Server
(as)
Application (client)
5. Access Token Grant
{ "access_token": "ACCESS_TOKEN", "token_type": "bearer", "expires_in": 2592000, "refresh_token": "REFRESH_TOKEN", "scope": "openid email"}
User (resource owner)
User-agent (web browser)
Auth Server
(as)
Application (client)
1. User authorization request
2. User authorizes application
3. Authorisation code grant
4. Access Token Request
5. Access Token Grant
Les flows additionnels
Device Flow
Comment donner un token à un périphérique qui n’a pas (ou peu) de UI ?
SAML 2 Bearer Assertion Flow
Quand une application fait partie d’une fédération et veut utiliser des ressources OAuth 2.0 de façon transparente
Proof of Possession (PoP)
Bearers Tokens
Quiconque met la main sur un de ces tokens peut l’utiliser et se faire passer pour vous
Avec la PoP, un RS va pouvoir vérifier que l’émetteur de l’Access Token est celui qui l’a reçu à l’origine (le Client)
Cible les attaques type man-in-the-middle ou l’utilisation abusive de tokens par un resource server mal intentionné
Scénario de validationClés asymétriques
ASC
access-token endpoint
code + public key
POST https://openam.example.com:8443/openam/oauth2/access_token
Content-Type: application/x-www-form-urlencoded Authorization: Basic base64(client_id:client_secret)
grant_type=authorization_code& code=1234& redirect_uri=<redirect_uri>& cnf_key=base64(clé publique)
1 Le client fournit sa clé publique
RSC
resource
access token
PUT https://snowcamp.io/speaker/guillaume/profile
Content-Type: application/json Authorization: Bearer <access_token>
{ “name”: “Guillaume Sauthier” }
2 Le client accède à la resource
ASRS
introspection endpoint
access token
{ "valid": true, "scopes": "openid profile email", "cnf":{ "jwk":{ "kty": "EC", "use": "sig", "crv": "P-256", "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } } }
3 Le RS “décode” le token et obtient la clé
RSC
resource
4
WWW-Authenticate: Bearer error=“signing_request”; value=“<nonce>”
Le RS vérifie le client
OpenId Connectune application d’OAuth 2.0
En bref ?
Une façon standard d’obtenir des infos relatives à l’utilisateur authentifié, basée sur OAuth 2.0
OAuth 2.0 décrit comment protéger l’accès aux ressources
OpenId Connect standardise une resource dédiée aux informations utilisateurs et défini les scopes pour pouvoir y accéder
Et concrètement ?
Activation basée sur la présence du scope dans la requête d’autorisation
Avec l’Access Token, le Client peut demander à l’AS le profil de l’utilisateur connecté
openid
Le schéma
AS +
RSC
user-info endpoint
access token
Il n’y a pas que ça
OpenId Connect définit un objet ‘id_token’, retourné avec l’Access Token
Clé de session
Contient des info “techniques”: provenance, destination, identification
JWT signé
Vérification de la provenance
Qu’est ce qu’un JWT ?
JSON Web Token
Transporte du JSON de manière sécurisée
Signature (authenticité)
Encryption (confidentialité)
UMAUser Managed Access
Et celui-là, y sert à quoi ?
Partage de resources entre personnes
Délégation d’autorité (au serveur d’autorisation)
Contrôle des partages d’accès spécifiques à des ressources que je possède
UMALe partage de photos
AS RqP REQUESTING
PARTY
C CLIENT
RO RESOURCE
OWNER
RS RESOURCE
SERVER
AS AUTHORIZATION
SERVER
Authentification Partage de ressource Configuration
PAT
AS RqP REQUESTING
PARTY
C CLIENT
RO RESOURCE
OWNER
RS RESOURCE
SERVER
AS AUTHORIZATION
SERVER
Authentification
AAT
AS RqP REQUESTING
PARTY
C CLIENT
RO RESOURCE
OWNER
RS RESOURCE
SERVER
AS AUTHORIZATION
SERVER
Tentative d’accès Autorisation Vérification Ressource retournée
RPT
PAT
AAT
UMA 2.0
Finalisé pour S1 2017
Un alignement sur OAuth 2.0
Simplifie la compréhension pour l’utilisateur et le déployeur
Nouveaux cas d’utilisation
Fournisseurs d’identités multiples
Conclusion
OAuth 2.0 pour accéder à ses propres ressources
OpenId Connect pour accéder à son propre profil utilisateur
UMA pour partager avec d’autres ses propres ressources
Q&A