C'est le plus classique, proche de CAS et/ou proxy CAS :
CAS | OIDC |
---|---|
Server | IPD ou OpenID provider ou Authorization server |
Service | Client ou RP (Relying Party) |
/login | /authorization |
/serviceValidate | /token |
Paramètres : | |
service | client_id & redirect_uri & state |
ticket |
|
gateway | prompt=none |
renew | prompt=login |
Un peu similaire : | |
proxy ticket (valide une fois) | access token (valide un certain temps) |
PGT | refresh token |
Comparé à CAS, le client (service) doit s'enregistrer sur l'IDP pour avoir un "client_id
" et un "client_secret
".
Flow | response_type | response_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.
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 :
postmessage
(notamment chez google en non standard avec redirect_uri=postmessage
: http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.html)http://connect2id.com/products/server/docs/config/core#op-authz-responseModes
https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html