“Sign-in using your facebook, google, linked-in or twitter account…” Porté notamment par les grands acteurs des réseaux sociaux, Oauth est devenu un standard difficilement contournable dans le paysage de la fédération d’identité. Authentifier c’est s’assurer qu’une entité est bien celle qu’elle prétend être. Oauth, quant à lui, se définit comme un “framework” d’autorisation permettant à des applications d’accéder aux données d’un utilisateur en lui demandant sa permission. Pourtant un usage important (Sign-in) semble être l’authentification… Simple question de sémantique ? Ou réelle subtilité, qui mal comprise, pourrait nous conduire à de mauvaises implémentations ? En ayant a cœur de répondre à cette question, cette présentation propose de regarder “sous le capot” de ce protocole. De Oauth 1.0 a Oauth 2.0 comment est-ce que cela fonctionne ? est-ce vrai qu’un token d’accès Oauth peut être réutilisé pour “usurper une identité” ? Et par rapport à SAML & OpenId : est-ce différent ou complémentaire ?

1. Oauth : un protocole
d'autorisation qui
authentifie ?
Maxime Féroul
Directeur Technique / KYOS IT
SECURITY
Application Security Forum - 2012
Western Switzerland
7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains
https://www.appsec-forum.ch

2. 2
# who -m
 Ingénieur Informatique & Télécom (ESIGETEL /
France)
 15 ans d'expérience : web-hosting & sécurité
 Co-fondateur de Kyos IT Security (2002) : 10 ans ;)
– Pen-testing & intégration & IAM
– Recherche EU : SEINIT, DEMONS,...
– Spacecom : le wifi est correct ?
 Domaines de prédilection : en ce moment J2ee &
IAM

3. 3
Agenda
Contexte : Social Login
Oauth 2.0 : Sous le capot
Implicit Flow : ou Implicit Flaw ?
Mitigation : La bonne implémentation

4. 4
Perturbation atmosphérique...
 Poursuite de la décentralisation des SI
 Utilisation de plateformes “tierces”, en
dehors de son domaine de sécurité
Nouveaux défis pour
le contrôle d'accès
Identités Multiples,
BYOD, “Information and
user centric”, ...

5. ...et toujours le même “Graal“
SIMPLICITÉ
UTILISATEUR,
FACILITÉ DE MISE
EN OEUVRE
&
SÉCURITÉ

6. 6
Emergence du “Social Login“
Utiliser les services d'authentification
d'une plateforme de réseau social

7. Social Login – Pourquoi ?
 Pour l'utilisateur
– Moins de login & mot de passe
– Meilleure gestion de ses identités
• Facebook → sites perso., linkedin → sites pro., …
• Meilleur « contrôle » : révoquer les applications

8. Social Login – Pourquoi ?
 Pour le fournisseur de
service
– Enregistrement simplifié
– Information plus fiable
– Plus d'information !

9. Social Login – Comment ?
 Etablir un « lien de confiance », fédérer les identités
 Déléguer
l'authentification et
l'autorisation
 Echanger des
informations sur
l'identité

10. Standards : Maelström ?
Connotation “web
Framework / Oauth 2.0 / end-user”
message Web Service
Web Centric API
Délégation de l'autorisation
Global & très modulaire
WS-Security, WS-
Federation, WS-
User
Connotation
Trust,... SOAP, SAML Centric REST,
“Microsoft & XML assertion UMA
JSON
IBM”
Framework / service “couche identité” au
d'identité dessus de OAuth 2.0
Profile, Authentification,
protocol, session, attributs Autorisation
bindings,... d'identité,...
Authentification,
SSO, Federation
Connotation
“Standard Entreprise”

11. Oauth 2.0 – Emergence
 Facebook, Google, Salesforce,...
REST, Simplicité, “designed for the web...”

12. 12
Agenda
Contexte : Social Login
Oauth 2.0 : Sous le capot
Implicit Flow : ou Implicit Flaw ?
Mitigation : La bonne implémentation

13. 13
Password anti-pattern
Bonjour BLOG, j'aimerais aussi que tu
publies mes “posts” sur Facebook ?
Pas de problème, donne moi ton login et ton
mot de passe Facebook, je m'y connecterais
en ton nom pour mettre à jour ton profil...
Tu m'excuses mais j'ai moyennement confiance en toi BLOG, tu ne
peux pas faire autrement que stocker mes “crédentiels” ?

14. 14
Oauth 2.0 – Framework d'autorisation
Permettre à des applications
et des fournisseurs de services
d’accéder à des données d’un
utilisateur en lui demandant sa
permission.

15. Oauth 2.0 – Rôles
Resource Client Authorization Resource
Owner Server Server
Par exemple :
Un internaute Utilise un blog En s'authentifiant via Facebook et
pour également publier ses
« posts » sur son profil

16. 16
Oauth 2.0 – Principe
2. S'authentifie et autorise
l'application (client)
Authorization
Server
3. Délivre le token
1. Accède au d'accès Délègue
service
l'autorisation
Resource
Client Server
4. Accède à la ressource
protégée

17. 17
Oauth 2.0 – Spécification
 Client type & profile
– Confidential, public & WebApp, user agent, native
 Endpoints
– Authorization, Token, Redirection
 Plusieurs types de « jeton d'autorisation »
– Authorization Code, Implicit, Resource Owner Password
Credentials, Client Credentials
– Des requêtes et réponses pour chaque type

18. 18
Oauth 2.0 – Question de départ
Oauth : un protocole d'autorisation qui authentifie ?
 Ok pour le password anti-pattern et l'autorisation
– Mais alors quel rapport avec le social login ?
– Comment “authentifier” ?
 Authentifier c'est obtenir des attributs d'identité
et prouver/valider qu'ils sont justes
Oauth permet d'accéder à des données d'identité !

19. 19
Oauth 2.0 – Comment authentifier ?
1.) BLOG demande à BORIS l'autorisation
d'aller récupérer chez Facebook les données
relatives à son identité pour l'authentifier.
Profil Boris
Nom
Prénom
Email
Login
2.) BORIS s'authentifie chez Facebook
et autorise BLOG à lire ses données
d'identité.

20. 20
Agenda
Contexte : Social Login
Oauth : Sous le capot
Implicit Flow : ou Implicit Flaw ?
Mitigation : La bonne implémentation

21. 21
Oauth 2.0 – Implicit Flow
RECHERCHE DE LA
SIMPLICITÉ
 Délivrance « directe » du token d'accès
 Moins d'échanges
 Application mobile (native)
 Application JavaScript (user-agent)

22. 22
Exemple – Authentification Facebook
Sign in via
Facebook
Redirect vers Facebook OAuth Implicit request
AppId,
redirectUri(blog.jsp)
Authentificatio
n
OAuth Implicit response + Autorisation
Redirect vers redirectUri(blog.jsp) de AppId
+AccessToken(xxxx)
Get
/blog.jsp?AToken=xxxx
Get
/graphAPI?AToken=xxxx
JSON object
userId=Boris
Welcome Boris !

23. 23
Access Token – Attention !
« ...This specification does not
provide any methods for the
resource server to ensure that
an access token presented to
it by a given client was issued
to that client by the
authorization server. »
Source : draft-ietf-oauth-
v2-31

24. 24
Implicit Flow – Usurpation
AccessToke
Auth.+ Auto.
n
Get
/ninjagame.jsp?ATo Get
ken=ABXYZ /graphAPI?AToken=ABXYZ
userId=Boris
Welcome on NinjaGame
Boris !
Get
/blog.jsp?AToken Get
Réutilisation =ABXYZ /graphAPI?AToke
du token ! n=ABXYZ
userId=Boris
Welcome Boris !

25. 25
La « spec. » nous avais prévenu...
«... Authenticating Resource Owners to clients is out of
scope for this specification.
Any specification that uses the authorization process
as a form of delegated end-user authentication to
the client (e.g. third-party sign-in service) MUST NOT
use the implicit flow without additional security
mechanisms such as audience restricting the access
token that enable the client to determine if the access
token was issued for its use. »
Source : draft-ietf-oauth-
v2-31

26. 26
Est ce que cela nous concerne ?
N'est ce pas plutôt un « problème » pour facebook, google, et consorts ?
 Oui si nous implémentons “nous-même” ou sans les
framework proposés
 Oui si nous vérifions des implémentations
 Oui pour notre culture et une meilleure
compréhension d'Oauth ;)

27. 27
Agenda
Contexte : Social Login
Oauth : Sous le capot
Implicit Flow : ou Implicit Flaw ?
Mitigation : La bonne implémentation

28. Mitigation – Implicit Flow
 Restreindre l'audience / valider le token d'accès avant
d'authentifier
– Signed request (Facebook JavaScript SDK)
– Service de validation du token

29. 29
Mitigation – Server Side Flow
Sign in via
Facebook
Redirect vers Facebook OAuth Authorization
request
AppId, redirectUri(blog.jsp)
Authentification
OAuth Authorization response + Autorisation de AppId
Redirect vers redirectUri(blog.jsp) +Code(xxxx)
Get /blog.jsp?Code=xxxx
OAuth Access Token request
AppId, Code,
Lié à l'AppId redirectUri(blog.jsp)
donc invalide AccessToken=yyyy
pour une autre
app ! Get
/graphAPI?AToken=yyyy
JSON object
userId=Boris
Welcome Boris !

30. 30
Mitigation – OpenId Connect
Une extension de Oauth 2.0
 UserInfo endpoint
– Fournisseur d'information
IDENTITY d'identité
Layer
 ID token objects
OAUTH 2.0 – Informations sur les évenements
Layer d'authentification (i.e audience,
contexte, temps,...)

31. 31
Conclusion
 Un protocole d'autorisation ...
 … mais qui peut servir à authentifier ...
 … à condition de l'implémenter correctement.
Les mécanismes de sécurité existent, il faut veiller à
les utiliser et à les vérifier.
… au prix d'un peu de compléxité ...
« Il n'y a pas de simplicité véritable, il n'y a que des simplifications »
Léon Paul Farge

32. 32
Questions?
 Principales Sources
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
by John Bradley
http://www.independentid.com/2011/04/oauth-does-it-authenticate-wellyes-and.html by
Phil Hunt
http://vennofidentity.org/
by Eve Maler
http://oauth.net/2/
http://tools.ietf.org/html/draft-ietf-oauth-v2-31
http://openid.net/connect/
https://developers.facebook.com/docs/concepts/login/
https://developers.google.com/accounts/docs/OAuth2

33. 33
Merci/Thank you!
 Contact:
maxime.feroul@kyos.ch
http://www.kyos.ch
Slides:
http://slideshare.net/ASF-WS/presentations