La Grande Famille OAuth 2.0
0 j'aime571 vues
Le document présente OAuth 2.0 et ses mécanismes de partage sécurisé des ressources en ligne, en abordant les bases, les flux d'autorisation, et les enjeux de sécurité. Il discute également d'OpenID Connect et de l'User Managed Access (UMA) pour la gestion des accès et le partage de ressources. En conclusion, OAuth 2.0 permet d'accéder à ses propres ressources, OpenID Connect à son profil utilisateur, et UMA à la délégation de partage de ressources.
La Grande Famille OAuth 2.0
- 1. La Grande Famille OAuth 2.0 Comment partager ses ressources de manière sécurisée sur Internet Guillaume Sauthier @sauthieg [email protected]
- 2. Agenda Pourquoi ? OAuth 2.0, les bases OpenId Connect, une application d’OAuth 2.0 UMA, ca se complique
- 3. Pourquoi ? un nouveau standard
- 4. L’existant Single 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)
- 5. 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 ?
- 6. Les besoins modernes Standard 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
- 7. OAuth 2.0 les bases, les flows, la PoP
- 8. Bonjour OAuth 2.0 Standard IETF (RFC 6749) Utilise du JSON Basé sur des tokens Access Token, Refresh Token Consentement Différents flows pour acquérir son token
- 10. Les flows de base password 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
- 12. User (resource owner) User-agent (web browser) Auth Server (as) Application (client) 1. User authorization request
- 13. User (resource owner) User-agent (web browser) Auth Server (as) Application (client) 2. User authorizes application click
- 14. 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
- 15. 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>
- 16. 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" }
- 17. 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
- 18. 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
- 19. 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é
- 21. 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
- 22. 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
- 23. 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é
- 24. RSC resource 4 WWW-Authenticate: Bearer error=“signing_request”; value=“<nonce>” Le RS vérifie le client
- 25. OpenId Connect une application d’OAuth 2.0
- 26. 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
- 27. 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
- 29. 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
- 30. Qu’est ce qu’un JWT ? JSON Web Token Transporte du JSON de manière sécurisée Signature (authenticité) Encryption (confidentialité)
- 32. 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
- 33. UMA Le partage de photos
- 37. 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
- 38. 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
- 39. Q&A