2.1.4. ID token
Un id token ou jeton
d'identité est un jeton de sécurité qui contient des
déclarations concernant l'authentification d'un utilisateur final par un
serveur d'autorisation lors de l'utilisation d'un client, et
éventuellement d'autres déclarations demandées. Le jeton
d'identité est représenté sous la forme d'un JSON Web
Token (JWT) avec signature cryptographique (JWS).
Les déclarations suivantes sont utilisées dans
le jeton ID pour tous les flux OAuth 2.0 utilisés par OpenID
Connect (on a cité là que les déclarations
obligatoires et quelques unes qui peuvent l'être ou non selon le cas. Il
en reste d'autres qui ne seront pas cités):
iss: Identifiant de l'émetteur pour
l'émetteur de la réponse. La valeur iss est une URL sensible
à la casse utilisant le schéma https qui contient des composants
de schéma, d'hôte et, éventuellement, de numéro de
port et de chemin d'accès et aucun composant de requête ou de
fragment.
sub: Identifiant du sujet. Un identifiant
localement unique et jamais réaffecté au sein de
l'émetteur pour l'utilisateur final, qui est destiné à
être consommé par le client, par exemple, 24400320 ou
AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. Il ne doit pas dépasser 255
caractères ASCII. La sous-valeur est une chaîne sensible à
la casse.
aud: Public(s) auquel ce jeton d'identité
est destiné. Il doit contenir le client_id OAuth 2.0 de la partie
utilisatrice comme valeur d'audience. Il peut également contenir des
identifiants pour d'autres publics. Dans le cas général, la
valeur aud est un tableau de chaînes sensibles à la casse. Dans le
cas spécial courant où il n'y a qu'une audience, la valeur aud
peut être une chaîne unique sensible à la
casse.
exp
Heure d'expiration à partir de
laquelle le jeton d'identité ne doit pas être accepté pour
le traitement. Le traitement de ce paramètre nécessite que la
date / heure actuelle doit être antérieure à la date /
heure d'expiration répertoriée dans la valeur. Sa valeur est un
nombre JSON représentant le nombre de secondes à partir de
1970-01-01 T 0:0:0 Z mesuré en UTC jusqu'à la date /
heure.
iat: Heure à laquelle le JWT a
été émis. Sa valeur est un nombre JSON représentant
le nombre de secondes à partir de 1970-01-01 T 0:0:0 Z mesuré en
UTC jusqu'à la date / heure.
auth_time: Heure à laquelle
l'authentification de l'utilisateur final s'est produite. Sa valeur est un
nombre JSON représentant le nombre de secondes à partir de
1970-01-01 T 0:0:0 Z mesuré en UTC jusqu'à la date / heure.
Lorsqu'une demande max_age est effectuée ou lorsque auth_time est
demandé en tant que revendication essentielle, cette revendication est
obligatoire,sinon, son inclusion est facultative.
nonce:
Valeur de chaîne utilisée pour associer une session
client à un jeton d'identité et pour atténuer les attaques
de relecture. La valeur est transmise sans modification de la demande
d'authentification au jeton ID. S'il est présent dans le jeton
d'identité, les clients doivent vérifier que la valeur de
réclamation nonce est égale à la valeur du
paramètre nonce envoyé dans la demande d'authentification. S'ils
sont présents dans la demande d'authentification, les serveurs
d'autorisation doivent inclure une réclamation nonce dans le jeton
d'identité, la valeur de réclamation étant la valeur nonce
envoyée dans la demande d'authentification. Les serveurs d'autorisation
ne devraient effectuer aucun autre traitement sur les valeurs non
utilisées. La valeur nonce est une chaîne sensible à la
casse.
Voici un exemple non normatif de l'ensemble de revendications
(l'ensemble de déclarations JWT) dans un jeton
d'identification :
Figure 2.4:
Exemple d'un ID Token
2.1.5. OAUTH
2.0
OAUTH 2.0 est un protocole qui sert à faire de la
délégation de l'accès et de l'autorisation. Le but
étant de savoir ce qu'on est autorisé à faire. Il fait
intervenir quatre acteurs principaux à savoir: le client,
l'Authorization Server AS, le Resource Owner RO et le Resource Server RS.
? Flow OAuth 2:
OAuth 2 propose différents types de flows. Le flow est
le processus de délivrance de l'access token. Le type de flow à
utiliser dépend le plus souvent du type de l'application, mais d'autres
facteurs peuvent également entrer en jeu comme le niveau de confiance
accordé au client.
Pour les applications web s'exécutant côté
serveur, le flow utilisé est l'Authorization Code Flow. Par
conséquent, c'est celui que nous allons traiter dans ce document.
? Terminologie OAuth 2:
Dans chaque flow, OAuth 2 garde la même terminologie.
Autrement dit, les acteurs concernés par chacun des flows gardent la
même terminologie. Ces acteurs sont:
? Le Resource Owner RO: c'est l'entité
qui octroie les droits d'accès à une ressource
protégée. Typiquement, l'utilisateur.
? Le Client: c'est l'application ou le
service qui souhaite accéder à une ressource
protégée au nom du RO.
? L'Authorization Server AS: c'est le serveur
qui est chargé d'authentifier le RO. C'est aussi lui qui fournit les
jetons d'accès Access Token.
? Le Resource Server RS: c'est le serveur qui
détient la ressource protégée.
? User Agent UA: Agent utilisé par le
RO pour interagir avec le client (par exemple, un navigateur ou une application
native).
? Authorization Code Flow:
a) Le Client envoie à
l'AS une requête composée de trois
éléments: le clientID qui va identifier le client
auprès de l'AS, la callback url qui sera
utilisée par l'AS pour recontacter le client et le
scope qui peut être un email, un profil, une date de naissance, ....
Ces informations sont demandées par le client au
RO par l'intermédiaire du UA.
b) L'AS reçoit la requête et
demande au RO de s'identifier.
c) Le RO entre ses identifiants à
travers le UA
d) Si les identifiants sont acceptés par
l'AS, ce dernier utilise la callback url pour rediriger le
UA. Le client va l'intercepter. Dans cette
url, le client trouvera un authorization code qui a
été fourni par l'AS. Ce code est passé
par référence et a une durée de vie limitée et donc
à usage unique.
e) Le client contacte l'AS
avec l 'authorization code.
f) L'AS renvoie un JWT dans le cas où
le code d'autorisation est valide. Cette JWT contient:
? Un access token qui permet d'accéder à la
ressource avec une durée de vie limitée
? Et un refresh token qui permet de rafraîchir l'access
token
Figure 2.5:
Illustration du fonctionnement d'OAuth2 - Authorization code
flow
| 
