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.
5. 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
6. Augmentation des Cloud-enabled App?
Source : https://blog.ironcorelabs.com/the-proliferation-of-under-protected-oauth-tokens-4a3847544b93
7. 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/
8. Ça vous dit quelque chose?
Source:https://lipis.github.io/bootstrap-social/
10. 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 ?
13. 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
14. 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
16. 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.
17. 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
18. 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!
19. 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.
20. 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 …
21. 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
22. É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
27. 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
30. 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.
31. Oauth 2.0 terminologie: « Grant »
• Authorization code grant
• Implicit grant
• Resource owner password credentials grant
• Client credentials grant
• Refresh token grant
32. 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
48. 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
49. Ça vous rappel de quoi?
Source:https://lipis.github.io/bootstrap-social/
50. 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
53. 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
54. 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
• …
55. 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)
56. « 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
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 !
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.
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.