sécuriser ses ap is avec oauth2 jug montpellier 16 avril 2014
DESCRIPTION
Présentation d'oauth 2 et d'openid connect au Jug Montpellier. Elle traite la question de l'utilisation d'une api par une application tierce et d'authentifier les utilisateurs de cette application.TRANSCRIPT
● 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
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
Répartion des services d’authentification
Avant OAuth
● Si une application tierce voulait accéder à votre compte, vous lui donniez votre mot de passe.
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
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
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
Pourquoi utiliser OAuth 2 ?
Serveur d’autorisations
Serveur de ressources
Application tierce
Utilisateur
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
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.
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.
Le flux authorization_code
Le flux implicit
Le flux client_credentials
Le flux password
Le scope
● Permet de limiter les accès du client● Permet à l’utilisateur de valider les droits du
client
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
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é
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
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○ …
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 :
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 :
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é.
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
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
OpenId Connect
● Volonté de simplifier l’authentification
● Une version d’OpenId basée sur OAuth 2
● Specification finale publiée fin février 2014
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
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.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
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/