La Grande Famille OAuth 2.0

La Grande Famille OAuth 2.0Comment partager ses ressources de manière sécurisée sur Internet

Guillaume Sauthier @sauthieg

guillaume.sauthier@forgerock.com

Agenda

Pourquoi ?

OAuth 2.0, les bases

OpenId Connect, une application d’OAuth 2.0

UMA, ca se complique

Pourquoi ?un nouveau standard

L’existantSingle Sign-On propriétaire

Habituellement basé sur des cookies (same origin policy)

Cross-Domain SSO (form auto-submit)

Fédération SAML

Standard OASIS

Nativement cross-domain

Les Service Providers (SP) délèguent l’authentification à l’Identity Provider (IdP)

Tout ca marche bien, mais …Single Sign-On propriétaire est … propriétaire

Intéropérabilité minimale

Couplage fort avec le fournisseur d’identité

Fédération SAML est … compliquée

Mise en oeuvre difficile

Pas très mobile-friendly

Qui aime encore le XML ?

Les besoins modernesStandard endossé par l’industrie

Facilité d’utilisation

Application ubiquitaires (web, mobile, desktop, …)

Risques limités

Ne pas partager ses credentials

Contrôle sur les autorisations déléguées (révocation, …)

Implémentation du consommateur relativement simple

OAuth 2.0les bases, les flows, la PoP

Bonjour OAuth 2.0Standard IETF (RFC 6749)

Utilise du JSON

Basé sur des tokens

Access Token, Refresh Token

Consentement

Différents flows pour acquérir son token

Client Resource Server

Authz Server

autorisation scope!

vérification scope?

accès

Les flows de basepassword

Le plus direct, le moins sécurisé

Expose les crédentials de l’utilisateur

implicit

Pour les applications mobiles, applications JS “one-page”

Sécurité du token non garantie, pas de refresh token

client_credentials

Lorsque l’application a ses propres credentials

authorization code

Pour les applications web server-side

authorization codepas à pas

User (resource owner)

User-agent (web browser)

Auth Server

(as)

Application (client)

1. User authorization request

User (resource owner)

User-agent (web browser)

Auth Server

(as)

Application (client)

2. User authorizes application

click

User (resource owner)

User-agent (web browser)

Auth Server

(as)

Application (client)

3. Authorization code grant

HTTP/1.1 302 Redirect

Location: http://openig.example.com:8080/id_token/openid/callback?code=1234&state=xxxx

User (resource owner)

User-agent (web browser)

Auth Server

(as)

Application (client)

4. Access Token Request

POST https://openam.example.com:8443/openam/oauth2/access_token Content-Type: application/x-www-form-urlencoded Authorization: Basic base64(client_id:client_secret)

grant_type=authorization_code& code=1234& redirect_uri=<redirect_uri>

User (resource owner)

User-agent (web browser)

Auth Server

(as)

Application (client)

5. Access Token Grant

{ "access_token": "ACCESS_TOKEN", "token_type": "bearer", "expires_in": 2592000, "refresh_token": "REFRESH_TOKEN", "scope": "openid email"}

User (resource owner)

User-agent (web browser)

Auth Server

(as)

Application (client)

1. User authorization request

2. User authorizes application

3. Authorisation code grant

4. Access Token Request

5. Access Token Grant

Les flows additionnels

Device Flow

Comment donner un token à un périphérique qui n’a pas (ou peu) de UI ?

SAML 2 Bearer Assertion Flow

Quand une application fait partie d’une fédération et veut utiliser des ressources OAuth 2.0 de façon transparente

Proof of Possession (PoP)

Bearers Tokens

Quiconque met la main sur un de ces tokens peut l’utiliser et se faire passer pour vous

Avec la PoP, un RS va pouvoir vérifier que l’émetteur de l’Access Token est celui qui l’a reçu à l’origine (le Client)

Cible les attaques type man-in-the-middle ou l’utilisation abusive de tokens par un resource server mal intentionné

Scénario de validationClés asymétriques

ASC

access-token endpoint

code + public key

POST https://openam.example.com:8443/openam/oauth2/access_token

Content-Type: application/x-www-form-urlencoded Authorization: Basic base64(client_id:client_secret)

grant_type=authorization_code& code=1234& redirect_uri=<redirect_uri>& cnf_key=base64(clé publique)

1 Le client fournit sa clé publique

RSC

resource

access token

PUT https://snowcamp.io/speaker/guillaume/profile

Content-Type: application/json Authorization: Bearer <access_token>

{ “name”: “Guillaume Sauthier” }

2 Le client accède à la resource

ASRS

introspection endpoint

access token

{ "valid": true, "scopes": "openid profile email", "cnf":{ "jwk":{ "kty": "EC", "use": "sig", "crv": "P-256", "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } } }

3 Le RS “décode” le token et obtient la clé

RSC

resource

4

WWW-Authenticate: Bearer error=“signing_request”; value=“<nonce>”

Le RS vérifie le client

OpenId Connectune application d’OAuth 2.0

En bref ?

Une façon standard d’obtenir des infos relatives à l’utilisateur authentifié, basée sur OAuth 2.0

OAuth 2.0 décrit comment protéger l’accès aux ressources

OpenId Connect standardise une resource dédiée aux informations utilisateurs et défini les scopes pour pouvoir y accéder

Et concrètement ?

Activation basée sur la présence du scope dans la requête d’autorisation

Avec l’Access Token, le Client peut demander à l’AS le profil de l’utilisateur connecté

openid

Le schéma

AS +

RSC

user-info endpoint

access token

Il n’y a pas que ça

OpenId Connect définit un objet ‘id_token’, retourné avec l’Access Token

Clé de session

Contient des info “techniques”: provenance, destination, identification

JWT signé

Vérification de la provenance

Qu’est ce qu’un JWT ?

JSON Web Token

Transporte du JSON de manière sécurisée

Signature (authenticité)

Encryption (confidentialité)

UMAUser Managed Access

Et celui-là, y sert à quoi ?

Partage de resources entre personnes

Délégation d’autorité (au serveur d’autorisation)

Contrôle des partages d’accès spécifiques à des ressources que je possède

UMALe partage de photos

AS RqP REQUESTING

PARTY

C CLIENT

RO RESOURCE

OWNER

RS RESOURCE

SERVER

AS AUTHORIZATION

SERVER

Authentification Partage de ressource Configuration

PAT

AS RqP REQUESTING

PARTY

C CLIENT

RO RESOURCE

OWNER

RS RESOURCE

SERVER

AS AUTHORIZATION

SERVER

Authentification

AAT

AS RqP REQUESTING

PARTY

C CLIENT

RO RESOURCE

OWNER

RS RESOURCE

SERVER

AS AUTHORIZATION

SERVER

Tentative d’accès Autorisation Vérification Ressource retournée

RPT

PAT

AAT

UMA 2.0

Finalisé pour S1 2017

Un alignement sur OAuth 2.0

Simplifie la compréhension pour l’utilisateur et le déployeur

Nouveaux cas d’utilisation

Fournisseurs d’identités multiples

Conclusion

OAuth 2.0 pour accéder à ses propres ressources

OpenId Connect pour accéder à son propre profil utilisateur

UMA pour partager avec d’autres ses propres ressources

Q&A

Resources

https://www.flickr.com/photos/clement127