oauth2 & openid connect
TRANSCRIPT
Agenda
● Oauth2 concepts● OpenID connect Concepts● Oauth2 & OpenID connect with OpenAM
Oauth2● Oauth2 defini dans la RFC 6749 (
https://tools.ietf.org/rfc/rfc6749.txt)
● Oauth2 est un protocole d'authorisation seulement (Il ne permet pas l'authentification, permise via OpenID connect)
● 4 Flux disponibles :
– Authorization Code– Implicit grant– Resource Owner Password– Client Credentials Grant
Oauth2 Concepts● OAuth2 définit 4 rôles bien distincts :
– Le détenteur des données (Resource Owner) : généralement vous-même.
– Le serveur de ressources (Resource Server) : serveur qui héberge les données dont l’accès est protégé (par exemple Google qui stocke les informations de votre profil).
– Le client (Client Application) : une application demandant des données au serveur de ressources (cela peut être votre application PHP côté serveur, une application Javascript côté client ou une application mobile par exemple).
– Le serveur d’autorisation (Authorization Server) : serveur qui délivre des tokens (ou jetons) au client.
Oauth2 Concepts● Tokens
– Le token d’accès (Access Token) : c’est le plus important car c’est lui qui permet au serveur de ressources d’autoriser la mise à disposition des données d’un utilisateur.
– Le token de renouvellement (Refresh Token) : ce token est délivré au même moment que le token d’accès. (Le Refresh token est disponible qie avec les flux authorization code et ressource owner password grant)
● Scope– Le client envoie les scopes qu’ils souhaitent utiliser lors de la demande
d’autorisation.
– Il convient que les scopes demandes soit permis par le serveur d'autorisation.
Authorization Code Grant
Quelle cinematique utiliser (1) ?
● Authorization Code :– ll doit être utilisé dès que possible et tout particulièrement quand le client
est un serveur web. Permet d’obtenir un token d’accès de longue durée qui pourra être renouvelé via un token de renouvellement (si le serveur
d’autorisation le permet).– Exemple :
● Détenteur des données (Resource Owner) : vous● Serveur de ressources (Resource Server) : un serveur Google● Client (Client Application) : un site internet quelconque● Serveur d’autorisation (Authorization Server) : un serveur Google
Implicit Grant
Quelle cinematique utiliser (2) ?
● Implicit Grant :– Il doit être utilisé quand l’application se trouve côté client (typiquement
une application Javascript). Il ne permet pas d’obtenir de token de renouvellement (refresh token)
– Exemple :
● Détenteur des données (Resource Owner) : vous● Serveur de ressources (Resource Server) : un serveur Facebook● Client (Client Application) : un site internet utilisant AngularJS par
exemple● Serveur d’autorisation (Authorization Server) : un serveur Facebook
Resource Owner Password Credential Grants
Quelle cinematique utiliser (3) ?● Resouce Owner Password Credentials Grant :
– Avec ce type d’autorisation, les identifiants (et donc le mot de passe) sont envoyés au client et ensuite au serveur d’autorisation. Il est donc impératif qu’il y ait une confiance absolue entre ces 2 entités.
– Il est donc principalement utilisé lorsque le client a été développé par la même autorité que celle fournissant le serveur d’autorisation.
– Exemple :
● Détenteur des données (Resource Owner) : vous ayant un compte sur le site acme.com de la société Acme
● Serveur de ressources (Resource Server) : la société Acme exposant son API à api.acme.com
● Client (Client Application) : le site internet acme.com de la société Acme● Serveur d’autorisation (Authorization Server) : un serveur de la société
Acme
OpenID connect
● OpenID connect est Oauth2 + Authentication :– OpenID Connect 1.0 est un simple layer d'identite construit au dessus
de oauth2.
– Il permet a des clients de verifier leur identite aupres d'un serveur d'authorization, et d'obtenir des informations sur l'utilisateur d'une facon REST-like.
OpenID connect
● Les roles definis dans OpenID connect sont :– End User (OAuth 2.0 resource owner), dont les informations sont
accedees par l'application.
– Relying Party (RP) (OAuth 2.0 client) qui accede aux donnees proteges de l'utilisateur.
– OpenID Provider (OP) (OAuth 2.0 authorization server and also resource server) qui contient les donnees de l'utilisateur, et permet les acces.
– Dans le cas d'un deploiement OpenID, OpenAM joue ce role d'access.
● De meme, OpenID Connect utilise les 4 flux presentes pour prcedemment pour Oauth2.
OpenID Connect Concepts (1)
● Une requete OpenID connect est specifie en utilisant : – Grant Types for OpenID Connect
– Type of Flow response_type Tokens Returned
– Authorization Code code Authorization code
– Implicit id_token ID token
– Implicit id_token token ID token and access token
● OpenID connect retourne 2 tokens :– Id_token
– Acces token
OpenID Concepts (2)
● ID Token :– L'ID token se decompose en 3 parties :
● header● payload● Signature
– Le header et la payload sont encodes en base 64, et peuvent etre faciment lus en decodeant leur format en base 64.
– La signature est un hash des composants suivants: header, payload, secret.
– Le secret est la signauture du serveur, qui permet de verifier des tokens et d'en signer des nouveaux.
OpenID Connect Concepts (3)● Verification d'un ID Token :
– La verification d'un ID token contient environ une dizaine de points dont certains optionels.
– Est definit dans la spec openID Connect (3.1.3.7. ID Token Validation, http://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken)
– Certains points sont quasiment immediat a verifier (sujet, audience, validite, expiration …)
– D'autre points sont complexes (verfication de la signature, necessitant l'usage de libraies JWT pour verifier le token)
● Verification d'un access Token– De meme, il est possible de valider un access token, en utilisant le
champ at_hash de l'id_token et en calculant un hash a partir de l'access token.
OpenAM et OpenID Connect● OpenAM permet de definir un OpenID/Oauth2
provider et de meme client Oauth2● Interfacage :
– Provider● Definir un Oauth2/OpenID Server provider (IDP openID) en utilisant
OpenAM● Definir les scopes necessaires
– Client:● Enregistrer un Oauth2 Client (mode implicite) aupres de l'IDP
openID connect dans l'openAM (possibel de facon dynamique)● Recuperer 2 jetons dans la reponse: id_token et access_token● Validations de l'id_token
OpenID Connect Concepts (2)● Dans le cas de mode implicite, les 2 tokens sont
renvoyés dans la reponse. Exemple :● curl -i --cookie "iplanetDirectoryPro=$1" \
http://openam.example.com:18080/openam/oauth2/authorize \--data "realm=%2f&scope=openid%20profile&\response_type=id_token%20token&\client_id=myClientID&\redirect_uri=http://openam.example.com:18080/openid/cb-implicit.html&\decision=Allow"
● Location: http://openam.example.com:18080/openid/cb-implicit.html#access_token=295768a3-6303-47a0-b31a-5ab82d4f27be&scope=openid%20profile&id_token=eyAidHlwIjogIkpXVCIsICJraWQiOiAiU3lsTEM2Tmp0MUtHUWt0RDlNdCswemNlUVNVPSIsICJjdHkiOiAiSldUIiwgImFsZyI6ICJSUzI1NiIgfQ.eyAiYXRfaGFzaCI6ICJMZUlZbkduR3pDMEx5eUZNWk51S2hBIiwgInN1YiI6ICJkZW1vIiwgImlzcyI6ICJodHRwOi8vb3BlbmFtLmV4YW1wbGUuY29tOjE4MDgwL29wZW5hbS9vYXV0aDIiLCAidG9rZW5OYW1lIjogImlkX3Rva2VuIiwgImF1ZCI6IFsgIm15Q2xpZW50SUQiIF0sICJvcHMiOiAiZDBiNWJiNTItYWM2YS00NjRlLWJlMDItYTY3MjNmNGViZWQ2IiwgImF6cCI6ICJteUNsaWVudElEIiwgImF1dGhfdGltZSI6IDE0Njc4NDI4MTAsICJyZWFsbSI6ICIvIiwgImV4cCI6IDE0Njc4NDM0MTAsICJ0b2tlblR5cGUiOiAiSldUVG9rZW4iLCAiaWF0IjogMTQ2Nzg0MjgxMCB9.asSMNjQ29gqrXtLCkTigswFOhtAN-e8lfeU-nESmK0P09hA7OLhfpR10L1ta-f646i0i5728OVAqC7du0EP5Bmm9w1xL__JqMzCFXnHI-jYVGKGKVrGIVtIy9kS2Zj86E4zLTVsiy7egX-ZKXGZSTpNjD8E6yS51mL28Knwvt44&token_type=Bearer&expires_in=8399
Lecture Access token
● curl http://openam.example.com:18080/openam/oauth2/tokeninfo?access_token=295768a3-6303-47a0-b31a-5ab82d4f27be | json_pp
{"openid" : "", "expires_in" : 8312, "access_token" : "295768a3-6303-47a0-b31a-5ab82d4f27be", "token_type" : "Bearer","grant_type" : "token","profile" : "","scope" : ["openid","profile"],"realm" : "/"
}
Lecture des champs de l'id_token (partie 1, header)
● echo -n"eyAidHlwIjogIkpXVCIsICE6yS51mL28Knwvt44....." > id_token_file.txt
cat id_token_file.txt | cut -d "." -f 1 | base64 -d
{ "typ": "JWT", "kid": "SylLC6Njt1KGQktD9Mt+0zceQSU=", "cty": "JWT", "alg": "RS256"
}
Lecture des champs de l'id_token (partie 2, payload)
● cat id_token_file.txt | cut -d "." -f 2 | base64 -d
{ "at_hash": "LeIYnGnGzC0LyyFMZNuKhA", "sub": "demo", "iss": "http://openam.example.com:18080/openam/oauth2", "tokenName": "id_token", "aud": [ "myClientID" ], "ops": "d0b5bb52-ac6a-464e-be02-a6723f4ebed6", "azp": "myClientID", "auth_time": 1467842810, "realm": "/", "exp": 1467843410, "tokenType": "JWTToken", "iat": 1467842810 }