...

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

CAS	OIDC	SAML 2
Server

IPD ou OpenID provider

OP (OpenID Provider) ou Authorization

server

/

authorization_endpoint
/serviceValidate /p3/serviceValidate	token_endpoint	HTTP Artifact
	userinfo_endpoint	Attribute Query
Paramètres :


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

Comparé à CAS, le client (service (client) doit s'enregistrer sur le serveur (l'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 ArtifactRedirect")
fragment (implicit grant, #code#token=xxx, était possible avec CAS < 3.4.4 en mettant un "#" dans l'url "service", mais ne donne donnait accès qu'au ticket, pas plus)
form_post (à la SAML "HTTP PostPOST")

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)