sécuriser ses ap is avec oauth2 jug montpellier 16 avril 2014

Sécuriser ses APIs avec OAuth2

Damien BOISSIN - damien.boissin@web-education.net

16 avril 2014

● 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/