1. –
–
–
Oauth2 & OpenID Connect
Olivier Rivat
orivat@janua.fr
12 Juillet 2016

2. Agenda
● Oauth2 concepts
● OpenID connect Concepts
● Oauth2 & OpenID connect with OpenAM

3. 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

4. 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.

5. 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.

6. Authorization Code Grant

7. 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

8. Implicit Grant

9. 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

10. Resource Owner Password
Credential Grants

11. 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

12. 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.

13. 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.

14. 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

15. 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.

16. 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.

17. 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

18. 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=eyAidHlwIjogIkpXVCIsICJraWQiOiAiU3lsTEM2Tmp0MUtHUWt0RDlNdCswemNlUVNVPSIsICJj
dHkiOiAiSldUIiwgImFsZyI6ICJSUzI1NiIgfQ.eyAiYXRfaGFzaCI6ICJMZUlZbkduR3pDMEx5eUZNWk51S2hBIiwgInN1Yi
I6ICJkZW1vIiwgImlzcyI6ICJodHRwOi8vb3BlbmFtLmV4YW1wbGUuY29tOjE4MDgwL29wZW5hbS9vYXV0aDIiLCAidG
9rZW5OYW1lIjogImlkX3Rva2VuIiwgImF1ZCI6IFsgIm15Q2xpZW50SUQiIF0sICJvcHMiOiAiZDBiNWJiNTItYWM2YS00
NjRlLWJlMDItYTY3MjNmNGViZWQ2IiwgImF6cCI6ICJteUNsaWVudElEIiwgImF1dGhfdGltZSI6IDE0Njc4NDI4MTAsIC
JyZWFsbSI6ICIvIiwgImV4cCI6IDE0Njc4NDM0MTAsICJ0b2tlblR5cGUiOiAiSldUVG9rZW4iLCAiaWF0IjogMTQ2Nzg0M
jgxMCB9.asSMNjQ29gqrXtLCkTigswFOhtAN-e8lfeU-nESmK0P09hA7OLhfpR10L1ta-
f646i0i5728OVAqC7du0EP5Bmm9w1xL__JqMzCFXnHI-jYVGKGKVrGIVtIy9kS2Zj86E4zLTVsiy7egX-
ZKXGZSTpNjD8E6yS51mL28Knwvt44&token_type=Bearer&expires_in=8399

19. 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" : "/"
}

20. 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"
}

21. 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
}