1. Sécuriser ses APIs avec OAuth2
Damien BOISSIN - damien.boissin@web-education.net
16 avril 2014

2. ● De quoi allons-nous parler ?
● Avant OAuth
● Pourquoi utiliser OAuth
● Les différences entre la version 1 et 2
● Les différents flux d’autorisation
● Le scope
● Le refresh token
● Sécurité
● Comment sécuriser ses apis
● Comment implémenter un serveur OAuth2
● OpenId Connect

3. De quoi allons-nous parler ?
● OAuth 2 : protocole de délégation d’
autorisation d’accès à des APIs
● OpenId Connect : protocole de délégation d’
authentification

4. Répartion des services d’
authentification

5. Avant OAuth
● Si une application tierce voulait accéder à
votre compte, vous lui donniez votre mot de
passe.

6. Avant OAuth
● Les applications stockaient les mots de
passe des utilisateurs
● Les applications pouvaient accéder à l’
intégralité du compte de l’utilisateur
● Les utilisateurs ne pouvaient pas révoquer l’
accès d’une application
● Une application compromise exposait les
mots de passe des utilisateurs

7. Avant OAuth
● Plusieurs solutions présentants des
similitudes avec OAuth émergeaient
● Mais incompatibles entre elles
“We want something like Flickr Auth / Google
AuthSub / Yahoo! BBAuth, but published as an
open standard, with common server and client
libraries.”
Blaine Cook, April 5th, 2007

8. Pourquoi utiliser OAuth 2 ?
● L’application tierce ne connais plus le mot de
passe
● Son accès à l’api est restreint et validé par l’
utilisateur
● L’utilisateur peut révoquer l’accès de l’
application tierce
● La rfc 6749 décrit le framework OAuth 2

9. Pourquoi utiliser OAuth 2 ?
Serveur d’
autorisations
Serveur de
ressources
Application
tierce
Utilisateur

10. Terminologie
● Resource Owner : l’utilisateur
● Resource Server : l’API
● Authorization Server : serveur pour obtenir
un jeton d’accès
● Client : l’application tierce
● client_id : identifiant du client
● secret : mot de passe du client
● access_token : le jeton d’accès

11. Les différences de la version 2
● Le jeton expire
● Apparition des scopes
● Plus besoin de signer les requêtes
HMAC
Pensez à vérifier la version d’
OpenSSL que vous utilisez.

12. Les flux d’autorisation
Grant type Cas d’utilisation
authorization_code Application web
implicit Application pure js ou mobile
client_credentials Communication entre serveurs (sans notion d’
utilisateur)
password À n’utiliser qu’avec des applications de
confiances (parfois utilisé dans les clients
lourds)
Extension Pour obtenir un access token en utilisant un flux
particulier. E.g. en utilisant une assertion SAML
2.

13. Le flux authorization_code

14. Le flux implicit

15. Le flux client_credentials

16. Le flux password

17. Le scope
● Permet de limiter les accès du client
● Permet à l’utilisateur de valider les droits du
client

18. Le refresh token
● Permet au client de demander un nouveau
jeton d’accès quand le précédent a expiré
● Il n’est disponible que dans les flux
○ authorization_code
○ password

19. Sécurité
● Pour le flux autorisation_code
○ Le client doit utiliser le paramètre “state” pour se
prémunir d’une faille CSRF
● Pour le flux implicit
○ le serveur d’autorisation doit mettre à disposition
dans son API un moyen de récupérer les
informations d’un jeton pour vérifier qu’il lui était bien
destiné

20. Sécurité
● Clickjacking
○ le serveur d’autorisation doit renvoyer un header
nommé X-Frame-Options sur sa page d’autorisation
avec comme valeur DENY ou SAMEORIGIN

21. Sécuriser vos apis
● Header Authorization avec le jeton d’accès
(bearer)
● Le resource server doit valider le jeton. Il y a
plusieurs cas pour cela
○ Le resource server est regroupé avec l’authorization server
(cas le plus courant)
○ Le resource server affectue un requête auprès de l’
authorization server pour valider le jeton
○ L’authorization server signe le jeton et le resource server
vérifie la signature
○ …

22. Authorization_code :
obtention d’un code
https://one/auth/oauth2/auth?
response_type=code&state=blip&scope=userinfo&client_id=Maxicours&redirect_uri=http%3A%2F%
2Flocalhost%3A1500%2Fcode
?code=52372d8e-e352-449c-8118-69647cf56ef1&state=blip
?error=invalid_request&state=blip
Exemple d’adresse de redirection :
Exemple des paramètres de la
redirection en cas de succès :
Exemple des paramètres de la
redirection en cas d’erreur :

23. Authorization_code :
obtention d’un jeton
curl -i -X POST -H "Authorization:Basic TWF4aWNvdXJzOmJsaXBibG9w" -H
"Content-Type:application/x-www-form-urlencoded" -H "Accept:application/json;
charset=UTF-8" -d "grant_type=authorization_code&code=52372d8e-e352-449c-
8118-69647cf56ef1&redirect_uri=http%3A%2F%2Flocalhost%3A1500%2Fcode"
https://one/auth/oauth2/token
{"token_type":"Bearer","access_token":"7acb83b1-53bd-4105-9b46-5acfb095158f","
refresh_token":"2fbc99ff-488b-486a-983c-8ae0edc079c5","expires_in":3600,"scope":"
userinfo"}
{"error":"invalid_request","error_description":"'client_id' not found"}
Exemple d’appel :
Exemple de succès :
Exemple d’erreur :

24. Authorization_code :
utilisation d’un jeton
curl -i -H "Authorization:Bearer 7acb83b1-53bd-4105-9b46-5acfb095158f" https:
//one/auth/oauth2/userinfo
{"userId":"1d7bd712-2365-4872-960c-4aff73487ef0","firstName":"Kévin","lastName":"
BOEUF","username":"Kévin BOEUF","classId":"09-CM1 Olivier TYTGAT","login":"
kevin.boeuf","level":"CM1","schoolName":"Ecole Molière","uai":"0611043C","type":"
ELEVE"}
Exemple d’appel :
Exemple de succès :
En cas d’échec un code 401 est renvoyé.

25. OAuth 2 dans ent-core
● Support des flux authorization_code et
client_credentials
● Authorization server et resource server
séparé
● Communication entre l’authorization server
et et le resource server au travers du bus de
vertx pour valider les jetons

26. Librairies pour java
● Spring security oauth : https://github.com/spring-
projects/spring-security-oauth
● Apache oltu : http://oltu.apache.org/
● OAuth2-server : https://github.com/yoichiro/oauth2-server
● Réécriture d’une partie de la librairie
précédente pour la rendre asynchrone afin
de l’utiliser avec vertx : https://github.com/web-
education/oauth2-server

27. OpenId Connect
● Volonté de simplifier l’authentification
● Une version d’OpenId basée sur OAuth 2
● Specification finale publiée fin février 2014

28. OpenId Connect
● Scope, valeur obligatoire : openid
● Scope, valeurs facultatives :
○ profile
○ email
○ address
○ phone
○ offline_access
● Retour d’un id_token JWT à même temps
que l’access_token
○ ce token doit être vérifier en utilisant l’algorithme
décrit dans l’header de l’id_token

29. Json Web Token
● 3 parties en base64url séparées par des
points
○ header : {"typ":"JWT", "alg":"HS256"}
○ payload : {"iss":"joe", "exp":1300819380, "http:
//example.com/is_root":true}
○ la signature
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

31. References
● http://tools.ietf.org/html/rfc6749
● https://openid.net/connect/
● http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19
● http://janrain.com/blog/social-login-trends-across-web-q4-2013/
● http://heartbleed.com/
● http://web-education.net/fr/