Introduction oauth 2.0 et openid connect 1.0
Report
Marc-André TousignantFollow
Jun. 15, 2018•0 likes•828 views
Introduction oauth 2.0 et openid connect 1.0
Jun. 15, 2018•0 likes•828 views
Download to read offline
Report
Technology
Dans un monde où la mobilité devient omniprésente, où les applications et les services en ligne ont un besoin grandissant de s’échanger de l’information, des technologies qui permettent de soutenir cette transformation de façon sécuritaire sont nécessaires. Pour faire face à cette nouvelle réalité, Oauth et OpenID Connect ont vu le jour et en raison de leur adoption par des acteurs influents de l’industrie, leur utilisation est pratiquement devenue un incontournable. Cette présentation se veut un survol du « framework » Oauth 2.0 ainsi que du protocole OpenID Connect 1.0. Ensemble, nous prendrons connaissance des raisons d’être de chacune de ces technologies, de leurs particularités et de leur fonctionnement. Nous poursuivrons avec des mises en contexte concrètes et terminerons avec un survol des vulnérabilités associées.
Marc-André TousignantFollow
Recommended
Chp2 - Vers les Architectures Orientées ServicesLilia Sfaxi
Architectures orientées servicesDonia Hammami
OpenID Connect: An OverviewPat Patterson
Support de cours entrepise java beans ejb m.youssfiENSET, Université Hassan II Casablanca
Support JEE Servlet Jsp MVC M.YoussfiENSET, Université Hassan II Casablanca
Java entreprise edition et industrialisation du génie logiciel par m.youssfiENSET, Université Hassan II Casablanca
More Related Content
Slideshows for you
Sécurité des Applications Web avec Json Web Token (JWT)ENSET, Université Hassan II Casablanca
Json Web Token - JWTPrashant Walke
Introduction à ASP.NETAbdelouahed Abdou
Introduction to OpenID Connect Nat Sakimura
OIDC4VP for AB/C WGTorsten Lodderstedt
OAuth 2.0 with IBM WebSphere DataPowerShiu-Fun Poon
Similar to Introduction oauth 2.0 et openid connect 1.0
La Grande Famille OAuth 2.0Guillaume Sauthier
Vous avez dit protocoles Web d’authentification et d’autorisation ! De quoi p...Microsoft
Delegation d'authentificationSébastien Brault
Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...Philippe Beraud
Sécuriser ses ap is avec oauth2 jug montpellier 16 avril 2014Damien Boissin
Oauth2 & OpenID ConnectPascal Flamand
Introduction oauth 2.0 et openid connect 1.0
Introduction à OAuth 2.0 & OpenID Connect 1.0 Marc-André Tousignant OWASP Québec Juin 2018
Agenda • Un peu d’histoire sur Oauth • OAuth 2.0 • OpenID connect 1.0 • Vulnérabilités • Littérature • Questions
Qui suis-je ? • Marc-André Tousignant • Bac. Informatique, Université Laval • Analyste en sécurité pour le Groupe Financier Industrielle Alliance
Introduction
De plus en plus d’applications mobiles Number of avaible apps at Google Play from 2nd quarter 2015 to 1s quarter 2018 Q2 2015 – 1 670 113 Q1 2018 – 3 849 865
Augmentation des Cloud-enabled App? Source : https://blog.ironcorelabs.com/the-proliferation-of-under-protected-oauth-tokens-4a3847544b93
APIs, Microservice, Building blocks? Source : http://customerthink.com/5-disruptions-to-marketing-part-2-microservices-apis-2018-update/ Source: http://customerthink.com/5-disruptions-to-marketing-part-2-microservices-apis-2018-update/
Ça vous dit quelque chose? Source:https://lipis.github.io/bootstrap-social/
UN PEU D’HISTOIRE
Un peu d’histoire… • Avant Oauth … Source: Aaron Parecki – An introduction to Oauth 2 - 2012 Source: Brian Campbell – cloud identity summit 2012 slide What could go wrong ?
Un peu d’histoire… Avant OAuth ... « the password sharing anti- pattern »
Un peu d’histoire… ! facebook 2007-2010 2012
OAuth 1.0, un protocole complexe • Sécurité basé essentiellement sur la cryptographie • Les messages sont signés de manière individuelle • Support limité … Mobile … Natif … • Implémentation complexe et peu interopérable
OAuth 2.0, un peu plus simple, mais… • HMAC SSL/TLS • « Bearer token » [RFC 6750] • Meilleur flexibilité • Meilleur segmentation des responsabilités • L’interopérabilité reste un enjeu
OAUTH 2.0
C’est quoi exactement OAuth? OAuth 2.0 est un « open-standard authorization framework » qui permet à un utilisateur d'autoriser des applications [tierces] à accéder à ses ressources Web, sans partager ses informations d’authentification ("credentials ») grâce à un objet de sécurité appelé jeton d'accès. Il amène le concept d'accès délégués.
Quelques spécifications et extensions The OAuth 2.0 Authorization Framework RFC 6749 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC 7523 JSON Web Token (JWT) RFC 7519 The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC 6750 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC 7521 Oauth 2.0 Token Introspection RFC 7662 OAuth 2.0 for Native Apps RFC 8252 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) RFC 7800 Oauth 2.0 Token Revocation RFC 7009
OAuth ne devrait pas être utilisé pour … • Offrir un contrôle d’accès traditionnel • Faire de l’authentification • Faire de la fédération OAuth sert à faire de la délégation d’accès!
Oauth répond à quel problème ? À haut niveau, Oauth mitige le problème du « password anti-pattern » en permettant à deux entités d’échanger de façon sécuritaire de l’information.
Oauth répond à quel problème ? Imaginons que vous vous êtes inscrit au service « ShareAbeerApp » qui vous recommande des amis avec qui partager une bonne bière à partir de votre liste d’amis Facebook… Ce service est complètement fictif …
Bob Peux-tu me suggérer des amis ? Évidemment! Donne-moi simplement ton nom d’utilisateur et mot de passe de Facebook. Avec plaisir! User : ****** Pass : ****** User : ****** Pass : ****** Allo, je suis Bob! Voici ta liste d’amis, Bob! Voici des suggestions d’amis... Genial! Accès Facebook Photos Feed Publication Liste amis Utilisateur ShareAbeerApp Facebook
Évidemment! Tu n’as qu’à m’autoriser. Voici le lien... ShareAbeerApp me dit que vous voulez l’autoriser à accéder à quelque chose... Certainement ! Quelques étapes plus tard.. Voici la liste d’amis. Voici des suggestions d’amis... Genial! Bob Peux-tu me suggérer des amis ? Voulez-vous autoriser ShareAbeerApp à accéder à votre liste d’amis ? Accès Facebook Photos Feed Liste amis Publication Accès Facebook Photos Feed Publication Liste amis Utilisateur ShareAbeerApp Facebook
OAUTH 2.0 : terminologie
Oauth 2.0 terminologie : Acteurs • Resource Owner (RO) • Resource Server (RS) • Authorization Server (AS) • Client Authorization Server Resource Server ClientResource Owner Demande un jeton Utilise un jeton
Oauth 2.0 terminologie : Client Client confidentiel !! Client public
Oauth 2.0 terminologie : Token Authorization Code token Refresh token Access token (Type : Bearer)
Oauth 2.0 terminologie : Token Bearer token “A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of- possession).” — https://tools.ietf.org/html/rfc6750#section-1.2
Oauth 2.0 terminologie : Scope Authorization Server = ABC = XYZ
Oauth 2.0 terminologie : Revoke Authorization Server
Oauth 2.0 terminologie: « Grant » • « Authorization Grant » – Terme général utilisé pour décrire les informations d'identification intermédiaires représentant l'autorisation du propriétaire pour une/des ressources. – Sert d’abstraction … – Utilisé par un client pour obtenir un jeton – Plusieurs types de « Grant » sont définit par la spécification ainsi que plusieurs extensions.
Oauth 2.0 terminologie: « Grant » • Authorization code grant • Implicit grant • Resource owner password credentials grant • Client credentials grant • Refresh token grant
Oauth 2.0 terminologie: Enregistrement • Le client doit s’enregistrer à l’« authorization server » – Nom – URI de redirection – Scopes* – Cliend ID & Secret Exemple : client_id=ShareAbeerApp Client_secret=zjdE32kD2dd2apD3 *scope=api1 api2 redirect_uri=HTTPS://app.shareabeerapp.xyz
OAUTH 2.0 : « flows »
Oauth 2.0 flow: « Authorization code » *PKCE
Oauth 2.0 flow: « Authorization code » Resource Owner User-Agent 11 Client 33 22 Authorization Code33 Access token + Refresh token*55 Authorization Server Back Channel Front Channel Authorization code, URI de redirection et Client Id & Secret44 Client ID, scopes & URI de redirection11 Authentification du Resource Owner & consentement22
Authorization ServerAuthorization Server Oauth 2.0 flow: « Authorization code » Resource Owner User-Agent 11 33 22 Authorization Code33 Access token + Refresh token*55 Client Ressource Server 66 Requête + Access token Client ID, scopes & URI de redirection11 Authentification du Resource Owner & consentement22 Authorization code, URI de redirection et Client Id & Secret44
Oauth 2.0 : « Revoke »
Oauth 2.0 flow: « Implicit » !! !!
Oauth 2.0 flow: « Implicit » Resource Owner User-Agent 11 Client 33 22 Authorization Server Front ChannelAcess token33 Client ID, scopes & URI de redirection11 Authentification du Resource Owner & consentement22
Oauth 2.0 flow: « Password »
Oauth 2.0 flow: « Password » Resource Owner 11 Client Authentifiant du client & Authentifiant du RO22 Authorization Server Acess token + Refresh token*33
Oauth 2.0 flow: « Client Credentials » Machine-to-machine
Oauth 2.0 flow: « Client Credentials » Client Authentifiant du client11 Acess token + Refresh token*22 Authorization Server
OpenID Connect 1.0
Qu’est-ce que Openid Connect ? OpenID Connect Protocol Suite DynamicMinimal Core Discovery Dynamic Client Registration Session Management Form Post Response Mode Oauth 2.0 Core Oauth 2.0 Bearer Oauth 2.0 Assertions Oauth 2.0 JWT Profile Oauth 2.0 Responses JWT JWS JWE JWK JWA Webfinger
Nouvelles fonctionnalités • Authentification • ID token (JWT) • SSO – « Single logout » • « Userinfo endpoint » • Standardisation des « claims »
OpenID Connect: « Flow / token » Authorization code Code / ID token & access token & refresh token* Implicit ID token Implicit ID token & access token Hybrid Code & ID token / access token & refresh token Hybrid Code & access token / ID token & access token & refresh token* Hybrid Code & ID token & access token / ID token & access token & refresh token*
OpenID Connect: « Hybrid Flow » Resource Owner User-Agent 11 Client 33 22 Back Channel Front ChannelAuthorization Code + ID Token*33 Access token + Refresh token* + ID token**55 Authorization ServerAuthorization Server Client ID, scopes & URI de redirection11 Authentification du Resource Owner & consentement22 Authorization code, URI de redirection et Client Id & Secret44
Ça vous rappel de quoi? Source:https://lipis.github.io/bootstrap-social/
Connectez-vous avec … Resource Owner User-Agent 11 Client 33 22 Identifiant du client & URI de redirection11 Authentification du Resource Owner22 Authorization Code33 Access token + ID token55 Requête Userinfo endpoint66 Informations d’identité77 Authorization code, URI de redirection et Client Id & Secret44 Authorization ServerAuthorization Server
Vulnérabilités et Mitigations
Surface d’attaque “The Attack Surface describes all of the different points where an attacker could get into a system, and where they could get data out.” — https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet
Surface d’attaque Get /authorize ?client_id=nativeapp &scope=openid profile api1 api2 &redirect_uri=com.acme.nativeapp://cb &response_type=code &nonce &state &code_challenge Get com.acme.nativeapp://cb#Authorization_code • Plusieurs « endpoint » • Plusieurs paramètres • Jetons dans le URL • Header HTTP • …
Plusieurs vulnérabilités • Account hijacking « Connect attack » / « session fixation » – Utiliser le paramètre« state » – CSRF protection – Exigez un consentement de l’usager • Account hijacking « authorization code leak » – Enregistrer un callback URI « static » – Évitez les « third party » « HTTP referer » • Leaked client credentials threat – Protection des secrets? – Reset? • Replay replay replay… euh replay attack – « One-time use token » (AuthZ code & Refresh) – Restreindre l’audience (Access token) • Laziness, Cutting corners – RTFM … RTFRFC (lisez la spécification, comprenez-la, respectez-la)
« Threat model & best current practice » • OAuth 2.0 Threat Model and Security Considerations RFC6819 … 70 pages • OAuth 2.0 Security Best Current Practice draft- ietf-oauth-security-topics-06 … 31 pages
Littérature
Littérature
Références Articles d’introduction • https://www.statista.com/statistics/289418/number-of-available-apps-in-the-google-play-store-quarter/ • https://blog.ironcorelabs.com/the-proliferation-of-under-protected-oauth-tokens-4a3847544b93 • http://customerthink.com/5-disruptions-to-marketing-part-2-microservices-apis-2018-update/ Oauth RFCs • https://tools.ietf.org/html/rfc6749 • https://tools.ietf.org/wg/oauth/ • https://tools.ietf.org/html/rfc6750#section-1.2 • https://tools.ietf.org/html/rfc7636 OpenID Connect 1.0 • http://openid.net/connect/ Vulnérabilités • http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html Threat model • https://tools.ietf.org/html/rfc6819 • https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 Littérature • https://www.packtpub.com/application-development/mastering-oauth-2 • https://www.apress.com/gp/book/9781430268185 • https://oauth2simplified.com/ • http://shop.oreilly.com/product/0636920021810.do • https://www.manning.com/books/oauth-2-in-action
Questions ?
Editor's Notes
- L’objectif principal est de bien comprendre qu’est-ce que Oauth 2.0 et OpenID Connect, leur raison d’être et leur fonctionnement.
- Source: https://www.statista.com/statistics/289418/number-of-available-apps-in-the-google-play-store-quarter/
- Source : https://blog.ironcorelabs.com/the-proliferation-of-under-protected-oauth-tokens-4a3847544b93
- Source: http://customerthink.com/5-disruptions-to-marketing-part-2-microservices-apis-2018-update/
- Les fournisseurs de service tiers vous demandaient vos informations d’identités Ils conservaient les mots de passe des utilisateurs Ils avaient un accès complet au compte des utilisateurs Les utilisateurs ne pouvaient pas révoquer l’accès à une application à moins de changer leur mot de passe Un service compromis exposait le mot de passe des utilisateurs
- Reconnaissance du problème par les fournisseur de service Solutions : Google AuthSub, Facebook requests signed, Yahoo BBAuth, Flickr FlickrAuth, etc. 2007 - 2010 OAuth 1.0 est publié et standardisé RFC 5849 2012 – OAuth 2.0 est standardisé RFC 6749 Source: Aaron Parecki – Slide - An introduction to Oauth 2 - 2012
- Sécurité basé essentiellement sur la cryptographie Un message signé est lié à son origine Les messages sont signés de manière individuelle Si un seul message dans la communication est construit ou signé incorrectement, l'ensemble de la transaction sera invalidé Support limité Pas adapté pour le Mobile ou IoT Ne supporte pas les clients non-WEB Implémentation complexe et peu interopérable La « Crypto » c’est compliqué Cause des défis pour l’implémentation
- Conçu autour de l’utilisation des jetons « Bearer » [RFC 6750] Le jeton « Bearer » n’offre aucun mécanisme de sécurité en lui-même Peut-être volé et rejoué Support plus flexible Support des clients mobiles et des clients non-WEB Meilleur segmentation des responsabilités Contrairement à Oauth 1.0, la spécification de Oauth 2.0 définit les rôles et responsabilités du serveur d’autorisation et du serveur de ressource. L’interopérabilité reste un enjeux « Framework » plus de latitude potentielle problème d’interopérabilité Éléments partiellement définit (ex. Client registration, Discovery, etc.). Puisque OAuth 2.0 est plus un « framework » qu'un protocole comme OAuth 1.0, les implémentations de OAuth 2.0 sont moins susceptibles d'être naturellement interopérables avec d'autres implémentations OAuth 2.0. Malheureusement, la spécification OAuth 2.0 laisse partiellement ou totalement indéfini certains composants requis (ex. Client registration, Discovery, etc.).
- Plus précisément un « framework » de délégation d’accès !
- Oauth 2.0 core 31 révisions… Source: https://tools.ietf.org/wg/oauth/
- Federation ? Externalisation d’un IDP … comparable à avoir un seul IDP (plusieurs IDP dans un seul)… Federation vs Delegation
- Resource Owner (RO) Utilisateur et propriétaire du compte permettant d’accéder à une ressource (End-user). Il est celui qui peut accorder des accès à une ressource protégée. Resource Server (RS) Serveur hébergeant des ressources protégées appartenant à l'utilisateur. (Resource API) Authorization Server (AS) Serveur qui émet des jetons d'accès pour permettre à des clients d'accéder à des ressources protégées. Client Une application obtenant un jeton d’accès et effectuant des requêtes aux ressources protégées (au nom du propriétaire de la ressource). Client Application Types - Mobile applications - Web browsers - Desktop applications Web server
- Client confidentiel Une application qui est en mesure de garder/protéger un secret. Application WEB (Server-side application) Client publique Une application qui n’est pas en mesure de garder/protéger un secret. Application native & mobile, application javascript (User agent application)
- Jeton, de courte durée, utilisé pour accéder aux ressources protégées au nom d'un utilisateur ou d'un service. Jeton, de longue durée, utilisé par le client pour obtenir un nouveau « access token » lorsque l’ancien est expiré. Jeton temporaire utilisé comme monnaie d’échange par le client afin d’obtenir un « access token » et/ou un « refresh token ».
- Permet de définir la portée de l’« access token » (les accès qu’il représente) Permet d’appliquer le principe du moindre privilège Définit par une liste de « strings » délimités par des espaces Demandé par le client Le sens d’un « scope » et sa valeur n’est généralement connu que par l’« Authorization Server » Ex: « user_photos user_friends email »
- Permet de définir la portée de l’« access token » (les accès qu’il représente) Permet d’appliquer le principe du moindre privilège Définit par une liste de « strings » délimités par des espaces Demandé par le client Le sens d’un « scope » et sa valeur n’est généralement connu que par l’« Authorization Server » Ex: « user_photos user_friends email »
- * Généralement utilisé par les clients de type confidentiel*. Permet d’offrir des jetons de longue durée (Refresh token). Nécessite un « Browser » Consentement du « Resource Owner » Le client doit s’authentifier pour obtenir les jetons *Native apps Proof Key for Code Exchange (PKCE) RFC 7636
- Révoquer les accès délégués
- Utilisé par des clients publiques. Permet d’obtenir des jetons de courte durée. Le client n’a pas à s’authentifier Nécessite un « Browser » Consentement du « Resource Owner »
- * Sauf dans le cas combiné avec le PKCE pour les clients mobiles et natifs
- Utilisé par des clients considérés de confiance. Les informations d’authentification de l’utilisateur sont exposés au client. Permet d’obtenir des jetons de longue durée. Le client doit s’authentifier Pas de consentement
- Utilisé par des clients confidentiels pour accéder des informations qui ne sont pas associé à un utilisateur spécifique. (machine-to-machine) Permet d’obtenir des jetons de longue durée. Le client doit s’authentifier
- Standard d’identification Construit au dessus de Oauth 2.0 Notion d’identité et de session utilisateur Externalise l’authentification
- OpenID change le comportement des Flows et en ajoute un nouveau.
- Source : https://lipis.github.io/bootstrap-social/
- Source : http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html
- Account hijacking « Connect attack » Client account hijacking by connecting attacker's provider account Provider returns code by redirecting user-agent to SITE/oauth/callback?code=CODE Now the client must send code along with client credentials and redirect_uri to obtain access_token. Account hijacking « session fixation » Even if the client properly validates the state we are able to replace auth cookies on the provider with the attacker's account: using CSRF on login (VK, Facebook), header injection, or cookie forcing or tossing.
- Sources: https://tools.ietf.org/html/rfc6819 https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06
- Sources : https://www.packtpub.com/application-development/mastering-oauth-2 https://www.apress.com/gp/book/9781430268185 https://oauth2simplified.com/ http://shop.oreilly.com/product/0636920021810.do https://www.manning.com/books/oauth-2-in-action