Pages enfant
  • Elements de repères OpenID Connect (vs CAS & shibboleth)

Vous regardez une version antérieure (v. /wiki/pages/viewpage.action?pageId=588087302) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 3) afficher la version suivante »

Authorization code flow

C'est le plus classique, proche de CAS et/ou proxy CAS :

CASOIDC
Server

IPD ou OpenID provider ou Authorization server

Service

Client ou RP (Relying Party)

/login/authorization
/serviceValidate/token
Paramètres : 
serviceclient_id & redirect_uri & state
ticket

code

Un peu similaire :

 
proxy ticket (valide une fois)access token (valide un certain temps)
PGTrefresh token

Comparé à CAS, le service (client) doit s'enregistrer sur le serveur (IDP) pour avoir un "client_id" et un "client_secret".

Autres code flow

Flowresponse_typeresponse_mode
Authorization code"code"query
Implicit"id_token token" ou "id_token"fragment
Hybrid"code id_token" ou "code token" ou "code id_token token"fragment

Dans le cas "response_type=id_token", l'id_token contient toutes les claims demandés par le paramètre "scope".

Dans les autres cas, les claims doivent être récupérés en faisant une requête /userinfo avec l'access token.

response_mode

  • query (CAS, SAML "HTTP Artifact")
  • fragment (implicit grant, #code=xxx, possible avec CAS en mettant un "#" dans l'url "service", mais ne donne accès qu'au ticket, pas plus)
  • form_post (à la SAML "HTTP Post")

expérimental : 

http://connect2id.com/products/server/docs/config/core#op-authz-responseModes
https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

 

  • Aucune étiquette