OAuthSD V2

Après 5 ans d’existence, le code d’OAuthSD a démontré sa fiabilité. Cependant, il a été développé de façon progressive en suivant les évolutions d’OAuth 2.0 et d’OpenID Connect. Le code devenu abondant, dense et peu lisible nécessitait une réécriture.

Par ailleurs, les tests OIDF Conformance ont évolué, OAuthSD aussi : de nouveaux tests ont été effectués.

2021 : OAuthSD v2

A l’origine en 2016, il s’est agit de créer un serveur OIDC en encapsulant l’API oauth2-server-php dans un peu de code pour créer trois contrôleurs : Authorize, Token et Resource. Il fallait également intégrer au contrôleur Authorize des méthodes d’identification avancées multifacteurs.

Depuis, la surcouche oauthsd-core-php a pris beaucoup d’extension visant à renforcer la sécurité de l’authentification. En même temps, beaucoup de fonctionnalités d’OAuth 2.0 et d’OpenID Connect, omises dans l’API, ont impliqué de nouveaux développements.

De plus, certaines extensions d’OIDC (par exemple l’introspection) avaient été développées dans la surcouche, l’idée initiale étant de conserver l’API oauth2-server-php inchangée. Nous comptions alors sur le fait que cette API se développerait, ce qui n’a pas été le cas.

Enfin, nous avions pris le parti de distinguer les contrôleurs OAuth 2.0 et les contrôleurs OIDC, ce qui créait confusion et doublons.

Le code de la surcouche oauthsd-core-php était devenu abondant, dense et peu lisible.

Il est donc apparu nécessaire de réécrire le code :

L’application de la programmation orientée objets (OOP) a permis d’améliorer la lisibilité de la surcouche. On a également obtenu une meilleure vitesse de traitement, le temps de réponse étant réduit d’un facteur deux à cinq. Comme toujours s’agissant d’OOP, le gain de vitesse est obtenu au prix d’une augmentation de la mémoire utilisée. Notons que nous n’avons toujours pas utilisé de framework PHP, car l’expérience montre une dégradation inacceptable des performances et une utilisation prohibitive de la mémoire du serveur.

La création d’un objet "Identification" facilite grandement la création de nouvelles méthodes d’identification de l’utilisateur ou l’intégration d’OAuthSD dans un système d’identité existant.

Il est apparu que la distinction entre deux groupes de points d’entrée spécifiques pour OAuth 2.0 et OpenID Connect était inutilement complexe et redondante. Il n’y a maintenant qu’un seul jeu, composé des points d’entrée d’OIDC et de trois flux spécifiques d’OAuth 2.0. Le contrôleur Authorize fonctionne aussi bien selon OAuth2.0 et OIDC, en distinguant les appels OIDC avec la portée demandée ’openid’. Autre exemple, le contrôleur Introspect permet de valider aussi bien des jetons d’accès que des jetons d’identité signés (JWS) et meme des jetons encryptés (JWE)..

Un fork de l’API a été développé. Des fonctions auparavant développées dans la surcouche ont trouvé leur place naturelle dans l’API : l’introspection, les JWT cryptés (JWE), l’insertion de nouvelles déclarations dans le JWT (kid, acr), le traitement de la "Clé de vérification pour l’échange de code (PKCE)". Le contrôleur Resource a été amélioré et des petits ajustements ont été apportés sans s’imposer de restriction.

Un soin particulier a été apporté au traitement de la "Référence de classe de contexte d’authentification (ACR)", qui avait été omis de l’API. Cette fonctionnalité est fondamentale s’agissant de mettre en œuvre des pourvoyeur d’identification de niveau de sécurité différents. Chaque application peut alors exiger un niveau de sécurité minimum et rejeter des identifications insuffisamment sécurisées.

Le paramètre "max_age", qui avait été omis de l’API, est maintenant traité.

OAuthSD implémente maintenant le paramètre ’request’ sous sa forme JWT non signé et passé par valeur (ainsi que le prévoit le test de certification de l’OIDF). Cela répond à une recommandation de L’ANSSI.

Les commentaires dans le code ont été abondamment développés, avec de nombreuses références, afin d’offrir aux développeurs une bonne compréhension de mécanismes souvent très complexes. C’est écrit en anglais, nous sommes à la disposition des utilisateurs pour les aider au besoin.
La documentation sera refondue en conséquence. OIDC étant construit sur OAuth 2.0, l’idée directrice est que l’approche "par le haut" depuis OIDC simplifie considérablement la compréhension. D’autres penseront que OAuth 2.0 intègre les fonctionnalités d’OIDC, et qu’il est donc inutile d’en parler...
Commentaires détaillés et documentation abondante nous permettent de justifier pleinement la qualité de notre offre de transfert de compétence.

Les tests OIDF Conformance ont évolué, OAuthSD aussi, de nouveaux tests ont été effectués. Voyez : https://oa.dnc.global/web/-Tests-et.... Le résultat des tests est visible en ligne.