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. 13) afficher la version suivante »

Authorization code flow

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

CASOIDCSAML 2
Server

OP (OpenID Provider) ou Authorization Server

IDP
Service

Client ou RP (Relying Party)

SP
/login/authorization 

/serviceValidate

/p3/serviceValidate

/tokenHTTP Artifact
 /userinfoAttribute Query
Paramètres :  
serviceclient_id & redirect_uri & state
SAMLRequest
ticket

code

Artifact
gatewayprompt=noneisPassive
renewprompt=loginForceAuthn

Un peu similaire :

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

Comparé à CAS, le client (service) doit s'enregistrer sur l'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 Redirect")
  • 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 (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

Mapping eduPerson attributes to OIDC claims

https://wiki.refeds.org/display/GROUPS/OIDCre

 

  • Aucune étiquette