...
C'est le plus classique, proche de CAS et/ou proxy CAS :
| CAS | OIDC | SAML 2 |
|---|---|---|
| Server | OP (OpenID Provider) ou Authorization Server | IDP |
| Service | Client ou RP (Relying Party) | SP |
| /login |
| authorization_endpoint |
/serviceValidate /p3/serviceValidate |
| token_endpoint | HTTP Artifact |
| userinfo_endpoint | Attribute Query | |
| Paramètres : |
service | client_id & redirect_uri & state | |
ticket |
| Artifact |
gateway | prompt=none | isPassive |
renew | prompt=login | ForceAuthn |
| acr_values | AuthnContextClassRef | |
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".
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".
...
query(CAS, SAML "HTTP Redirect")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(SAML "HTTP POST")
...
Mapping eduPerson attributes to OIDC claims
https://wiki.refeds.org/display/GROUPS/OIDCreMapping+SAML+attributes+to+OIDC+Claims
Implémentations OpenID Connect
Apereo CAS
NB : le userinfo_endpoint est /profile