OpenID Connect OAuth Server dédié

Voyez : https://bshaffer.github.io/oauth2-server-php-docs/overview/jwt-access-tokens/

Configuration du serveur d’autorisations pour le jeton d’accès JWT

Dans la bibliothèque, cela se fait en définissant le paramètre de configuration "use_jwt_access_tokens" à ’true’ :

Pour la configuration de OAuthSD, le fichier /commons/configure_oauth.php et le fichier configure_oidc.php définissent tous deux la constante USE_JWT_ACCESS_TOKENS, fixée à ’false’ par défaut.

Avec les flux OpenID Connect, lorsqu’il est configuré sur ’true’, le contrôleur Token émet à la fois le jeton d’accès et le jeton d’identification en tant que JWT.

Use Case

Ecoutons Brent Shaffer [1] :

"vous pouvez utiliser les jetons d’accès JWT si vous avez des systèmes distribués et que vous devez valider l’authenticité d’un jeton auprès de plusieurs parties sans avoir à passer un appel réseau.

Par exemple, un jeton est attribué par le serveur d’autorisations. Ce jeton est un jeton Web JSON signé par la clé privée du serveur d’autorisations. Les serveurs de ressources (où les appels d’API sont effectués) sont répartis dans le monde entier et exécutent plusieurs applications. Tant que les serveurs de ressources disposent de la clé publique du serveur d’autorisations, qui n’a pas besoin d’être sécurisée, ils peuvent valider les jetons rapidement sans aucun appel réseau. Les jetons n’ont même pas besoin d’être persistés.

C’est un cas d’utilisation d’entreprise, mais il est très utile pour les systèmes distribués.."

Discussion

Cette fonctionnalité a été décrite en 2014, alors qu’OpenID Connect était en construction. Il visait probablement à donner aux utilisateurs d’OAuth2 la capacité de valider les jetons d’accès dans les serveurs de ressources.

Il faut également considérer le problème posé par OAuth : ce n’est pas un système d’authentification (mais d’autorisation) parce que le jeton d’accès est opaque et ne donne pas d’information sur l’utilisateur final. En incorporant l’ID de l’utilisateur dans le jeton JWT, on fait d’OAuth un système d’authentification ce qui permet de passer l’information sur l’utilisateur à des ressources protégées. C’est ce que Facebook fait avec ce qu’ils appellent le "signed request".

Avec cette fonctionnalité, les flux de codes d’autorisation OAuth 2.0 et OpenID Connect semblent très similaires.
Il faut cependant noter la différence entre jeton d’accès et jeton d’identité : ils ne sont notamment pas liés dans le temps. La notion de "session OIDC" repose sur la validité du jeton d’identité qui expire, alors que le jeton d’accès expire indépendamment, peut être rafraîchi ou peut ne pas expirer. Cette utilisation du jeton d’accès en tant que JWT ne peut donc remplacer le jeton d’identité d’OpenID Connect.

Les jetons JWT peuvent être utilisés en tant qu’OAuth 2.0 Bearer Tokens pour coder toutes les parties pertinentes d’un jeton d’accès dans le jeton d’accès lui-même au lieu d’avoir à les stocker dans une base de données. Cela pourrait s’avérer très utile avec les applications sans session (comme les applications à page unique), avec une latence réduite pour la validation de jeton.