CAS	OIDC
Server	IPD ou OpenID provider ou Authorization server
Service	Client ou RP (Relying Party)
/login	Authorization Endpoint/authorization
/serviceValidate	Token Endpoint/token
Paramètres :
`service`	`client_id` & `redirect_uri` & `state`
`ticket`	`code`
Un peu similaire :
proxy ticket (valide une fois)	access token (valide un certain temps)
PGT	refresh 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

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.

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 :

CORS AJAX
postmessage (notamment chez google en non standard avec redirect_uri=postmessage : http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.html)