OpenID Connect OAuth Server dédié

OAuthSD est-il compatible OPenID Connect ?

OAuthSD a pour ambition de se conformer aux spécifications de l’IETF telles qu’elles sont publiées par l’OPenID Foundation.
OAuthSD est 100% conforme en ce qui concerne le flux Authentication Code, voyez : OAuthSD vers la Certification OpenID ®.
Notez que :
 OAuthSD ne met pas en œuvre certains flux, voyez : OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).
 OAuthSD évolue vite et de nouveaux tests de conformité seront effectués,
 OAuthSD impose certaines restrictions qui vont dans le sens de la sécurité ; ainsi, le paramètre state est obligatoire dans les requêtes à Authorize, alors que la spécification ne l’exige pas.
 OAuthSD offre des fonctionnalités étendues qui, cependant, ne contredisent en rien les spécifications. Il en est ainsi du mécanisme SLI : les spécifications d’OIDC définissent tout ce qu’il faut pour la ré-authentification silencieuse (notamment avec le paramètre prompt=’none’), mais cela resterait à traiter par allers-retours entre le serveur et l’application cliente. OAuthSD traite cela au niveau du contrôleur Authorise à l’aide du cookie SLI, évitant aux développeurs un fastidieux travail d’adaptation des applications.
 OAuthSD apporte quelques ajouts à la spécification, sans influence sur la conformité. Ainsi, le contrôleur Authorize peut être interrogé en Ajax et retourner le temps de session restant. Voyez : Monitoring de l’état de l’authentification et SLO, Avertir de la fin de session OIDC et la prolonger.

Qu’est-ce qu’apporte OAuthSD en matière de sécurité ?

Les spécifications d’OIDC ne prennent pas en compte certaines menaces. Par exemple l’attaque "Broken End-User Authentication" n’est pas prise en compte par les spécifications, la preuve en est le fait que le paramètre state n’est pas obligatoire.
L’accent est mis sur l’éviction d’application cliente ou de user-agent douteux. Par exemple, il y a aujourd’hui 12 tests dans le controleur Authorize permettant d’éliminer des requêtes douteuses.

Dans le domaine de la sécurité, OAuthSD n’est pas seulement un serveur d’authentification mais un superviseur.

Par exemple, dans les pages de la rubrique "Surveiller", l’historisation des incidents est datée à mieux que la microseconde afin de faciliter le croisement des informations. Il faut pour cela que les autres historiques soient aussi à la microseconde [1].

OAuthSD comporte également un dispositif d’alerte de l’administrateur par E-mail ou SMS, ainsi qu’un interface pour le suivi et l’alerte avec PRTG.

L’historique des événements est dans un format compatible syslog afin de permettre leur traitement par des applications de détection d’intrusion, de suivi et d’alerte.

On peut lire des critiques sur certains flux, pourquoi les mettre en œuvre ?

Il faut considérer qu’un serveur OIDC est aussi sécurisé que le flux le moins sécurisé qu’il implémente.
Une caractéristique étonnante d’OAuth 2.0 est d’offrir des flux très peu sécurisés par rapport au flux Autorisation avec Code. Encore celui-ci n’est-il vraiment complet que dans sa version OpenID Connect (pas OAuth 2.0) qui met en œuvre le jeton d’identité.
Ouvrir la possibilité que le serveur réponde à des requêtes très diverses (telles que les flux implicites et hybrides) sans contrôler l’application cliente peut être considéré comme une faille de sécurité [2] !
Nous souhaitons mettre à disposition un serveur 100% compatible OpenID Connect. En même temps, les développeurs et administrateurs doivent être conscients qu’exposer le serveur aux flux implicites et hybrides est une faille de sécurité. Pour cette raison, une constante de configuration permet d’autoriser l’usage ou non du flux implicite. On pourrait ainsi ne répondre qu’aux requêtes de types Authorization Code et Autorisation de Serveur à serveur.

Peut-on tout faire avec le flux Authorization Code ?

Non, car il faut qu’il existe une URI de retour vers l’application cliente pour l’identifier. Cela exige le plus souvent une application de type Web. Sur ce sujet, voyez : Typologie des applications au regard de la sécurité des données et OIDC et les Application à page unique : exemple d’une belle mascarade !. Des applications natives peuvent satisfaire la condition, voyez par exemple : Applications natives : un exemple avec Windev.

Le flux Client Credentials est également intéressant pour l’accès d’une application aux ressources protégées.
Mais il est possible de se servir du flux Authorization Code pour cela, avec l’avantage du jeton d’Identité JWT qui peut définir notamment des autorisations ; voyez : OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo.

Que signifie "Il existe des informations complémentaires, connectez vous pour les voir" ?

Lorsque ce message apparait en bas d’un article, cela signifie qu’il existe des informations réservées aux utilisateurs privilégiés de ce site. Si vous avez les droits d’écriture sur la rubrique, vous serez autorisés à voir ce texte après vous être connecté.