OpenID Connect OAuth Server dédié

APACHE mod_auth_openidc

DnC — 2024-11-07T13:55:00Z

APACHE mod_auth_openidc est un module d'authentification pour le serveur HTTP Apache 2.x qui délègue l'authentification des utilisateurs à un fournisseur OpenID Connect. Cela permet de contrôler l'accès à tout ou partie d'un domaine Web.

Il est ainsi possible d'accéder à des applications sans avoir à les modifier pour OIDC.

Ce module permet à un serveur Web Apache 2.x de fonctionner en tant que partie de confiance OpenID Connect (RP) ou 'client' d'un fournisseur OpenID Connect (OP).

Il délègue l'authentification des utilisateurs à l'OP, dont il reçoit en retour un jeton d'identité (ID Token) contenant les informations d'identité de l'utilisateur.
Il transmet ces informations aux applications hébergées et protégées par le serveur Web Apache.

Le contenu et/ou les applications protégés peuvent être servis par le serveur Apache lui-même ou peuvent être servis depuis un autre endroit lorsqu'Apache est configuré en tant que proxy inverse devant le(s) serveur(s) d'origine.

See : https://github.com/zmartzone/mod_auth_openidc

Préparation

Tout d'abord il faut vérifier la présence du module mod_auth_openidc :

# apachectl -M
 ...
 auth_openidc_module (shared)
 ...

Si absent, il faut installer le module mod_auth_openidc.so :

# yum install mod_auth_openidc
 ...

et relancer Apache.

Configurer un VirtualHost

Dans l'exemple qui suit, un serveur à l'URL example.com comporte un répertoire '/protected' protégé par OIDC.

Il y a trois sections dans cet exemple : d'abord la définition du serveur, puis la configuration OIDC et enfin la définition d'un emplacement protégé par OIDC.

NameVirtualHost *:80
 
 
 ServerAdmin webmaster@example.com
 ServerName example.com
 ServerAlias www.example.com
 DocumentRoot /home/example/public_html/
 DirectoryIndex index.html
 ErrorLog /var/log/oidc/error.log
 CustomLog /var/log/oidc/access.log
 
 OIDCProviderMetadataURL https://oa.dnc.global/.well-known/openid-configuration
 OIDCClientID openidc_example
 OIDCClientSecret ...
 OIDCRedirectURI http://example.com/protected/redirect_uri
 OIDCCryptoPassphrase 
 OIDCJWKSRefreshInterval 3600
 
 
 AuthType openid-connect
 Require valid-user

OIDCProviderMetadataURL : URL du document de découverte (Discovery metadata). Par convention il s'agit du fichier openid-configuration se trouvant à la racine des documents de l'OP dans le répertoire /.well-known/.
OIDCClientID, OIDCClientSecret : les identifiants du module en tant que client de l'OP (ou relying party, RP).
OIDCRedirectURI : une URI factice qui doit pointer dans un répertoire protégé par ce module (dans notre exemple à l'intérieur du répertoire 'protected') mais ne doit PAS pointer vers un contenu. Il faut l'enregistrer en tant qu'URI de redirection dans la configuration du client sur l'OP.
OIDCCryptoPassphrase : un mot de passe aléatoire à des fins de cryptage de la session.
OIDCJWKSRefreshInterval : Durée de vie de l'authentification.

Déclarations renvoyées depuis OpenID Connect via le module Apache

Le module passe les déclarations du jeton d'identité ID_TOKEN aux applications hébergées et protégées par le serveur web Apache.

Par défaut, le module définit la variable REMOTE_USER sur la revendication id_token [sub], concaténée avec l'identifiant de l'émetteur de l'OP ([sub]@[iss]).

Les autres déclarations du jeton d'identité ID_TOKEN sont transmises dans les en-têtes HTTP et/ou les variables d'environnement avec celles (éventuellement) obtenues à partir du point de terminaison UserInfo.

La super globale $_SERVER contient ces déclarations sous la forme :
OIDC_XXX

On peut par exemple les lister comme suit :
PHP

foreach ($_SERVER as $key=>$value) {
if ( preg_match("/OIDC_/i", $key) ) {
echo "$key : $value";
}
}

Télécharger

Autorisation Apache Require

Les règles d'autorisation Apache Require standard peuvent être appliquées avec l'ensemble des déclarations fournies par le jeton d'identité.

...

Principes et organisation générale d'un déploiement OpenID Connect

DnC — 2019-11-16T14:57:55Z

Loin d'être une contrainte pour les différentes parties d'une grande entité, la délégation de l'authentification des utilisateurs et des applications à un serveur unique permet de déployer des applications et des serveurs de données protégées, dans des lieux différents et sous des maîtrise d'œuvre différentes, tout en assurant la sécurité des données.
L'entité coordonnant ces lieux et ces autorités devra cependant faire observer des règles pour le développement et le déploiement des applications.

Principes auxquels doivent se conformer les applications

1. Toutes les applications ( au moins celles manipulant des données confidentielles ), doivent être inscrites sur le serveur OpenID Connect de l'entité et lui déléguer l'authentification des utilisateurs.

2. Toutes les données confidentielles doivent se trouver sur des serveur de ressources ( par exemple des web-services ) appartenant à l'entité et dont l'accès est sécurisé à l'aide d'OpenID Connect.

Un tel service est d'ailleurs intégré au serveur OpenID Connect sous le nom "UserInfos".
On notera que cette obligation autorisera la bonne pratique de saisie unique des données.
Elle permettra également de tracer avec exactitude l'utilisation des données confidentielles.
Enfin, il sera possible de répondre de façon précise et exhaustive aux obligations du RGPD, notamment à une demande d'information de la part d'un utilisateur sur la détention et l'emploi de ses données personnelles.

3. On se limitera aux applications qui interrogent les serveurs de ressources confidentielles depuis un serveur privé de l'entité.
En effet, toutes les configurations d'applications, de serveurs et de ressources ne permettent pas d'identifier avec certitude une application cliente, et donc de distinguer les applications malveillantes. Sauf à admettre un risque de compromission.
Ce principe, en apparence anodin, impose en réalité une grande contrainte dans les flux d'authentification à utiliser selon la configuration des applications et des utilisateurs. Certaines configurations devront être interdites, sans céder à la commodité ou à la popularité de solutions admises par le grand public. Pour approfondir le sujet, voyez : Authentifier l'application.

Pour une meilleure sécurité, l'application devra être de type "web" et mettre en œuvre le flux d'autorisation avec code ( Authorization Code Grant ).

Implémentation du monitoring avec Javascript : exemples pour SPIP et WordPress

DnC — 2019-11-16T08:51:08Z

Implémentation du monitoring dans le plugin OpenID Connect client pour SPIP

Le site oa.dnc.global utilise ce plugin (il est client OIDC, le serpent se mord la queue !). Vous pouvez donc voir une étiquette en haut à gauche de la fenêtre qui traduit l'état du jeton d'accès lié à la connexion courante :

icône	Signification
	La connexion de l'utilisateur final n'est pas établie avec le serveur OIDC. Notez que l'utilisateur peut s'être connecté à l'application à l'aide de la méthode de connexion classique de SPIP.
	L'utilisateur final et l'application sont connectés par OIDC.
	Erreur générale, traduit malheureusement de multiples situations : perte de communication Internet, défaut de configuration du plugin, défaut d'inscription de l'application cliente sur le serveur OAuthSD, inscription de l'application sur un autre serveur, non compatible OAuthSD, login inconnu du serveur OAuthSD (l'utilisateur final n'est pas inscrit sur ce serveur), etc. Le message peut éventuellement être plus explicite : "authentication error", ...

Le Monitoring permet également de manager la session OIDC et notamment d'effectuer la déconnexion globale (SLO).
En cliquant sur l'icône, des popups apparaissent selon l'état de connexion.

Exemple du code Javascript (avec jQuery) utilisé pour SPIP. Le plugin insère ce code en pied de chaque page.

[SPIP]

/**
* Plugin OpenID Connect client pour SPIP
* OIDC Client Monitoring
* Interroge le contrôleur OIDC Authorize avec prompt=none pour afficher l'état de connexion.
* Voir également action_logout() dans oidcclient_options.php.
* Auteur : B.Degoy DnC
* Copyright (c) 2019 B.Degoy
* Licence GPL v3.0
*/
// OIDC Client Monitoring
php
include_spip('inc/oidcclient_configuration'); ?>
$(document).ready(function() {
// Ajouter l'étiquette si elle n'existe pas
if($('#oidc').length === 0){
$('
OIDC
')
.appendTo('nav')
.css('position','absolute')
.css('top','12px')
.css('left','3px')
.css('color','white')
.css('padding','3px');
}
var login = "";
var state = "";
if ( login !== "" ) {
// Si on est logé localement, surveiller qu'on l'est également sur OIDC
setInterval(function(){
$.ajax({
type : "get",
url : "",
data : { 'response_type' : 'code',
'client_id' : "",
'user_id' : login,
'state' : state,
'scope' : 'openid',
'prompt' : 'none',
},
statusCode : {
401 : function(){
// Non authentifié sur OIDC, déconnecter localement
var url_logout_public = "";
window.location.replace(url_logout_public);
},
200 : function (){
// Signaler la connexion
$('#oidc').css('background-color', '#8f8');
$('#oidc').text(' OIDC ');
},
},
error : function(obj,textStatus,errorThrown){
// Signaler qu'on ne sait pas
$('#oidc').css('background-color', 'red');
$('#oidc').text(textStatus + ' ' + errorThrown);
}
});
}, 2000);
} else {
// Signaler la déconnexion
$('#oidc').css('background-color', 'orange');
$('#oidc').text(' OIDC ');
}
});

Télécharger

Implémentation du monitoring dans une extension Wordpress

Le plugin est disponible sur Github.

Le code Javascript est inséré dans un hook appelé par la fonction bootstrap() de l'extension :
[PHP]

/**
* OAuthSD project https://oa.dnc.global
* OAuthSD OIDC plugin for WordPress
* Insert monitoring code in footer
* dnc1
* Author : bdegoy DnC https://degoy.com
* copyright (c) 2019 B.Degoy DnC
* Licence GPL v3.0
*/
function insert_monitoring() {
// Enqueue some jQuery UIs
wp_enqueue_script('jquery-ui-dialog'); // from WP core
// get registered script object for jquery-ui
global $wp_scripts;
$ui = $wp_scripts->query('jquery-ui-core');
// load the Smoothness theme from Google CDN
$protocol = is_ssl() ? 'https' : 'http';
$url = "$protocol://ajax.googleapis.com/ajax/libs/jqueryui/{$ui->ver}/themes/smoothness/jquery-ui.min.css";
wp_enqueue_style('jquery-ui-smoothness', $url, false, null);
// OIDC Client Monitoring
$thisuri = $_SERVER['REQUEST_URI'];
$absolutepath_this_plugin = plugin_dir_path( __FILE__ );
$url_this_plugin = plugins_url('', dirname(__FILE__) ) . "/openid-connect-generic";
$state = md5(wp_get_session_token());
// Server URLs
$settings = $this->settings;
$url_endpoint_login = $settings->endpoint_login;
$url_endpoint_token = $settings->endpoint_token;
$url_endpoint_userinfo = $settings->endpoint_userinfo;
$url_endpoint_logout = $settings->endpoint_end_session;
$parts = parse_url($url_endpoint_login);
$url_server = $parts['scheme'] . '://' . $parts['host'];
// OIDC user
$clientID = $settings->client_id;
// $userID = ???
// WP user
$user = get_user_by('id', get_current_user_id());
$login = $user->user_login;
$nom_auteur =$user->display_name;
// for info popup
$infos =
'
' . __('oidcclient:serveur_url','openid-connect-generic') . ' : . $url_server . '">' . $url_server . '' .
'
' . __('oidcclient:client_id','openid-connect-generic') . ' : ' . $clientID .
'
' . __('oidcclient:login_wp','openid-connect-generic') . ' : ' . $login .
//'
' . __('oidcclient:login_oidc_court','openid-connect-generic') . ' : ' . $userID .
'
' . __('oidcclient:nom_auteur','openid-connect-generic') . ' : ' . $nom_auteur;
// labels and messages
$msg_session_connected_no = __('oidcclient:session_connected_no','openid-connect-generic');
$msg_session_connected_yes = __('oidcclient:session_connected_yes','openid-connect-generic');
$msg_session_connected_error = __('oidcclient:session_connected_error','openid-connect-generic');
$msg_session_open = __('oidcclient:session_open','openid-connect-generic');
$msg_session_extend = __('oidcclient:session_extend','openid-connect-generic');
$msg_session_close = __('oidcclient:session_close','openid-connect-generic');
$msg_session_expires = __('oidcclient:session_expires','openid-connect-generic');
$lbl_yes = __('oidcclient:item_yes','openid-connect-generic');
$lbl_no = __('oidcclient:item_no','openid-connect-generic');
$lbl_t_session_restant = __('oidcclient:t_session_restant','openid-connect-generic');
$lbl_delai_reponse = __('oidcclient:delai_reponse','openid-connect-generic');
$lbl_infos_titre = __('oidcclient:lbl_infos_titre','openid-connect-generic');
// link to OIDC login
$link_login = $this->client_wrapper->get_authentication_url();
// link to logout page
$url_logout = esc_url($url_this_plugin . "/oidc_logout.php?url=" . $_SERVER['REQUEST_URI']);
echo <<
JSCODE
;
} //function

Télécharger

Notons qu'il faut insérer un bloc div en bas de page, ce qui est fait au moyen d'une action dans la fonction bootstrap en même temps que le hook de la fonction précédente :
[PHP]

//OIDC Monitoring
wp_enqueue_script("jquery");
add_action('wp_footer', array( $plugin, 'insert_monitoring'), 5);

Télécharger

API HTTP REST + TreeQL

DnC — 2019-10-11T06:27:21Z

OAuthSD expose maintenant une deuxième API HTTP REST. Comme la première (qui reste disponible) cette API permet d'automatiser certaines tâches autour du serveur d'authentification. Une application d'administration (supervision) peut ainsi contrôler les données du serveur.
Cette nouvelle API s'appuie sur php-crud-api. Les objets sont manipulés sous des format scalaires ou json simples. Elle offre plus de possibilités de requêtes en suivant le format TreeQL.

Remarque : Cette API pourrait remplacer l'API HTTP REST à moyen terme.

Sécurisation de l'accès à l'API et transmission du rôle de l'utilisateur final

La sécurisation de l'accès à l'API HTTP REST + TreeQL est effectué à l'aide d'un jeton d'identité au format JWT émis par l'application cliente.

Ce jeton transmet le rôle de l'utilisateur au moyen de la déclaration 'scope' prenant l'une des valeurs 'admin', 'writer', 'reader' and 'none'. Pour cela (voir Définition des scopes OIDC et généralités sur leur utilisation par les applications) :
l'application cliente doit utiliser OIDC et initialiser le flux d'autorisation avec code avec la demande d'autorisation (requested_scope) 'scope=privileges',
L'application cliente doit avoir été enregistrée avec la valeur 'privileges' dans la liste de Scopes disponibles (Available scopes),
une valeur parmi 'admin', 'writer', 'reader' and 'none' doit avoir été enregistrée dans la table users pour l'utilisateur final considéré.

Le jeton peut être passé dans l'URL (méthode GET), par POST ou par la méthode Authorization : Bearer.

Exemple d'appel avec la méthode GET :

https://oa.dnc.global/http.api/api.php/records/spip_users/1/?token=eyJ0eXAiOiJKV...

L'API valide le jeton JWT par introspection. OAuthSD garantit ainsi l'authenticité de l'application cliente. Voir : Vérification de l'origine de la requête reçue par un serveur de ressource.

En cas d'erreur d'authentification, l'API retourne un code HTTP 403 Forbidden et un corps vide.

Limitation de l'accès aux tables et aux champs

seules les tables 'users', 'clients', 'scopes', 'oidc_logs' sont accessibles.

L'authentification de l'utilisateur final conduit à définir les rôles 'admin', 'writer', 'reader' et 'none'. Le rôle 'admin' peut effectuer l'ensemble des opérations.

Pour le rôle "writer" :
dans la table 'public_keys', la seule opération permise est la lecture de la clé clé publique.
dans la table 'oauth_clients', l'accès au champ password est interdit.
dans la table 'oauth_users', l'accès au champ client_secret est interdit.

Pour le rôle 'reader' :
les restriction d'accès sont les mêmes que le rôle 'writer',
seules les opérations 'read' et 'list' sont autorisées.

Le rôle 'none' ne peut que lire la table 'oidc_logs'.

Opérations CRUD + List : Référence de l'API

Voyez également :
https://oa.dnc.global/http.api/spec/swagger/static/
https://editor.swagger.io/?url=https://oa.dnc.global/http.api/api.php/openapi

Sélections avancées

Sur les opérations de liste, vous pouvez appliquer des filtres et des jointures.

Les exemples suivants supposent la table suivante :

posts
id
titre
content		message

Filtres

Les filtres fournissent une fonctionnalité de recherche sur les appels de liste, en utilisant le paramètre "filter". Vous devez spécifier le nom de la colonne, une virgule, le type de correspondance, une autre virgule et la valeur que vous souhaitez filtrer.

Types de match supportés :

"cs" : contient une chaîne (la chaîne contient une valeur)
"sw" : commence par (chaîne commence par valeur)
"ew" : se termine par (chaîne se termine par valeur)
"eq" : égal (la chaîne ou le nombre correspond exactement)
"lt" : inférieur à (nombre inférieur à la valeur)
"le" : inférieur ou égal (le nombre est inférieur ou égal à la valeur)
"ge" : supérieur ou égal (le nombre est supérieur ou égal à la valeur)
"gt" : supérieur à (nombre supérieur à la valeur)
"bt" : entre (le nombre est entre deux valeurs séparées par une virgule)
"in" : in (le nombre ou la chaîne est dans une liste de valeurs séparées par des virgules)
"is" : est null (le champ contient la valeur "NULL")

Vous pouvez annuler tous les filtres en ajoutant un caractère "n", afin que "eq" devienne "neq". Exemples d'utilisation du filtre :

GET / records / categories? Filter = nom, eq, Internet

GET / records / categories? Filter = nom, sw, Inter

GET / records / categories? Filter = id, le, 1

GET / records / categories? Filter = id, ngt, 2

GET / records / categories? Filter = id, bt, 1,1

Filtres multiples

Les filtres peuvent être appliqués en répétant le paramètre "filter" dans l'URL. Par exemple l'URL suivante :

GET / records / categories ? Filter = id, gt, 1 & filter = id, lt, 3

demandera toutes les catégories "où id> 1 et id <3". Si vous vouliez "où id = 2 ou id = 4", vous devriez écrire :

GET / enregistrements / catégories ? Filter1 = id, eq, 2 & filter2 = id, eq, 4

Comme vous le voyez, nous avons ajouté un numéro au paramètre "filter" pour indiquer que "OR" au lieu de "AND" doit être appliqué. Notez que vous pouvez également répéter "filter1" et créer un "ET" dans un "OU". Comme vous pouvez également aller plus loin en ajoutant une lettre (a-f), vous pouvez créer presque n'importe quel arbre de conditions relativement complexe.

Notes :
Vous ne pouvez filtrer que sur la table demandée (pas sur la table incluse) et les filtres ne sont appliqués qu'aux appels de liste.

Sélection de colonne

Par défaut, toutes les colonnes sont sélectionnées. Avec le paramètre "include", vous pouvez sélectionner des colonnes spécifiques. Vous pouvez utiliser un point pour séparer le nom de la table du nom de la colonne. Plusieurs colonnes doivent être séparées par des virgules. Un astérisque ("*") peut être utilisé comme caractère générique pour indiquer "toutes les colonnes". Semblable à "include", vous pouvez utiliser le paramètre "exclude" pour supprimer certaines colonnes :

GET / enregistrements / catégories / 1 ? Include = nom
GET /records/categories/1 ?include=categories.name
GET /records/categories/1 ?exclude=categories.id

Sortie :

 {
 "nom": "Internet"
 }

Notes :
Les colonnes utilisées pour inclure des entités associées sont automatiquement ajoutées et ne peuvent pas être omises de la sortie.

Tri

Avec le paramètre "order", vous pouvez trier. Par défaut, le tri s'effectue par ordre croissant, mais en spécifiant "desc", cela peut être inversé :

GET / records / categories ? Order = nom, desc

GET / enregistrements / catégories ? Order = id, desc & order = name

Sortie :

 {
 "records": [
 {
 "id": 3
 "name": "développement Web"
 },
 {
 "id": 1
 "nom": "Internet"
 }
 ]
 }

Notes :
Vous pouvez trier sur plusieurs champs en utilisant plusieurs paramètres "ordre". Vous ne pouvez pas commander sur des colonnes "jointes".

Taille limite

Le paramètre "size" limite le nombre d'enregistrements renvoyés. Ceci peut être utilisé pour les N premières listes avec le paramètre "order" (utilisez l'ordre décroissant).

GET / records / categories ? Order = id, desc & size = 1

Sortie :

 {
 "records": [
 {
 "id": 3
 "name": "développement Web"
 }
 ]
 }

Notes :
Si vous souhaitez également connaître le nombre total d'enregistrements, vous pouvez utiliser le paramètre "page".

Pagination

Le paramètre "page" contient la page demandée. La taille de page par défaut est 20, mais peut être ajustée (par exemple à 50).

GET / records / categories ? Order = id & page = 1

GET / records / categories ? Order = id & page = 1,50

Sortie :

 {
 "records": [
 {
 "id": 1
 "nom": "Internet"
 },
 {
 "id": 3
 "name": "développement Web"
 }
 ],
 "résultats": 2
 }

Notes :
les pages non commandées ne pouvant pas être paginées, elles seront classées par clé primaire.

Jointures

Supposons que vous ayez une table des publications qui comporte des commentaires (formulés par les utilisateurs) et que les publications puissent avoir des balises. Les exemples suivants supposent le jeu de tables suivant :

posts	commentaires	utilisateurs	post_tags	tags
id	id	id	id	id
titre	post_id	nom d'utilisateur	post_id	nom
content	user_id	phone	tag_id
message	créé

Lorsque vous souhaitez répertorier les publications avec leurs commentaires, les utilisateurs et les balises, vous pouvez demander deux chemins "arborescents" :

messages -> commentaires -> utilisateurs
posts -> post_tags -> tags
Ces chemins ont la même racine et cette demande peut être écrite au format URL comme suit :

GET / records / posts ? Join = commentaires, utilisateurs & tags = join

Ici, vous êtes autorisé à laisser de côté la table intermédiaire qui lie les publications aux balises. Dans cet exemple, les trois types de relation de table (hasMany, belongsTo et hasAndBelongsToMany) sont en jeu :

"post" a beaucoup de "commentaires"
"commentaire" appartient à "utilisateur"
"post" a et appartient à beaucoup de "tags"

Cela peut entraîner les données JSON suivantes :

{
 "records": [
 {
 "id": 1,
 "title": "Bonjour tout le monde!",
 "content": "Bienvenue dans le premier message.",
 "created": "2018-03-05T20: 12: 56Z",
 "commentaires": [
 {
 id: 1,
 post_id: 1,
 identifiant d'utilisateur: {
 id: 1,
 nom d'utilisateur: "mevdschee",
 téléphone: null,
 },
 message: "Salut!"
 },
 {
 id: 2,
 post_id: 1,
 identifiant d'utilisateur: {
 id: 1,
 nom d'utilisateur: "mevdschee",
 téléphone: null,
 },
 message: "Salut encore!"
 }
 ],
 "Mots clés": []
 },
 {
 "id": 2,
 "title": "Le noir est le nouveau rouge",
 "content": "Ceci est le deuxième message.",
 "created": "2018-03-06T21: 34: 01Z",
 "commentaires": [],
 "Mots clés": [
 {
 id: 1,
 message: "drôle"
 },
 {
 id: 2,
 message: "informatif"
 }
 ]
 }
 ]

}

Vous voyez que les relations "belongsTo" sont détectées et la valeur de la clé étrangère est remplacée par l'objet référencé. Dans le cas de "hasMany" et "hasAndBelongsToMany", le nom de la table est utilisé comme nouvelle propriété de l'objet.

Opérations par lots

Lorsque vous souhaitez créer, lire, mettre à jour ou supprimer, vous pouvez spécifier plusieurs valeurs de clé primaire dans l'URL. Vous devez également envoyer un tableau au lieu d'un objet dans le corps de la demande pour créer et mettre à jour.

Pour lire un enregistrement de cette table, la demande peut être écrite au format URL sous la forme suivante :

GET / records / posts / 1,2

Le résultat peut être :

[
 {
 "id": 1,
 "title": "Bonjour tout le monde!",
 "content": "Bienvenue dans le premier message.",
 "created": "2018-03-05T20: 12: 56Z"
 },
 {
 "id": 2,
 "title": "Le noir est le nouveau rouge",
 "content": "Ceci est le deuxième message.",
 "created": "2018-03-06T21: 34: 01Z"
 }

]

De même, lorsque vous souhaitez effectuer une mise à jour par lot, la demande au format URL est écrite comme suit :

PUT / records / posts / 1,2

Où "1" et "2" sont les valeurs des clés primaires des enregistrements que vous souhaitez mettre à jour. Le corps devrait contenir le même nombre d'objets qu'il y a de clés primaires dans l'URL :

[
 {
 "titre": "Titre ajusté pour ID 1"
 },
 {
 "titre": "Titre ajusté pour ID 2"
 }

]

Ceci ajuste les titres des messages. Et les valeurs de retour sont le nombre de lignes définies :

1,1

Ce qui signifie qu'il y avait deux opérations de mise à jour et que chacune d'entre elles avait défini une ligne. Les opérations en mode batch utilisent des transactions de base de données, de sorte qu'elles réussissent ou échouent (les transactions réussies sont renvoyées).

API HTTP REST

DnC — 2019-06-25T17:30:00Z

OAuthSD expose une API HTTP REST qui permet d'automatiser certaines tâches autour du serveur d'authentification. Une application d'administration (supervision) peut ainsi contrôler les données du serveur.
L'API s'appuie sur HTTPFoundation de Symphony. Les objets sont manipulés au format Collection+JSON ou sous un format json simple.

Remarque : Il existe également une API HTTP REST + TreeQL.

L'API répond à une unique action « http.api » qui va gérer trois paramètres :

- un format : c'est le nom de l'API réellement implémentée : json, collectionjson.
- un type (ou une collection) : le type des données qu'on veut utiliser : auteurs, users, clients ...
- une ressource : l'identifiant unique d'un contenu (un nombre entier).

Ces trois paramètres sont tout simplement ajoutés à la suite dans l'URL, séparés par des « / ». Seul le premier est toujours obligatoire, les autres sont ajoutés suivant ce que l'on veut manipuler. On se retrouve alors avec trois familles d'Url de requêtes.

Exemple de requête d'action :

https://oa.dnc.global/web/http.api/collectionjson/users/3

La deuxième forme peut également être complétée par des paramètres d'URL. Exemple :

Exemple de requête avec paramètres :

https://oa.dnc.global/web/http.api/collectionjson/users/?offset=10&length=10

L'API permet d'effectuer les opérations CRUD [1] sur une table de la base de données en fonction de la méthode de la requête HTTP GET, POST, PUT ou DELETE, si toutefois les permissions sont accordées.

L'API s'efforce de répondre à la spécification de sémantique HTTP 1.1.

Types

Pour s'interfacer avec une application de supervision, OAuth SD expose les types :
oidc_logs,
users,
clients
auteurs.
D'une façon générale, les types correspondent aux tables éponymes.
Sauf exception (voir la constante de configuration API_HTTP_CHAMPS_SENSIBLES), tous les champs d'une table peuvent être manipulés.

Formats

Dans le cadre d'OAuthSD, les objets sont manipulés aux formats suivants :

collectionjson
Ce format est assez lourd, retournant les données sous forme d'arrays associatifs et d'objets, ce qui permet de nombreuses applications. Voir : Collection+JSON.

Exemple : la requête :

https://oa.dnc.global/web/http.api/collectionjson/oidc_logs/?offset=3000&length=2

retourne :

{
"collection": {
"version": "1.0",
"href": "https://oa.dnc.global/web/http.api/collectionjson/oidc_logs/?offset=3000&length=2",
"items": [
{
"href": "https://oa.dnc.global/web/http.api/collectionjson/",
"links": [
{
"rel": "edit",
"href": "https://oa.dnc.global/web/http.api/collectionjson/"
},
{
"rel": "alternate",
"type": "text/html",
"href": "https://oa.dnc.global/web/urls_propres2_dist"
}
],
"data": [
{
"name": "id_oidc_log",
"value": "3400"
},
{
"name": "remote_addr",
"value": "173.208.157.186"
},
{
"name": "state",
"value": ""
},
{
"name": "client_id",
"value": "testopenid4"
},
{
"name": "user_id",
"value": "Unk"
},
{
"name": "datetime",
"value": "2019-03-06 03:04:09"
},
{
"name": "origin",
"value": "Authorize"
},
{
"name": "message",
"value": "2019-03-06 03:04:09 - 173.208.157.186 - Information : Authorize : Begin\n\n"
},
{
"name": "level",
"value": "1"
},
{
"name": "weight",
"value": "0"
},
{
"name": "errnum",
"value": "1"
}
]
},
{
"href": "https://oa.dnc.global/web/http.api/collectionjson/",
"links": [
{
"rel": "edit",
"href": "https://oa.dnc.global/web/http.api/collectionjson/"
},
{
"rel": "alternate",
"type": "text/html",
"href": "https://oa.dnc.global/web/urls_propres2_dist"
}
],
"data": [
{
"name": "id_oidc_log",
"value": "3401"
},
{
"name": "remote_addr",
"value": "173.208.157.186"
},
{
"name": "state",
"value": "fc06ce8d03c189c7af1167d2e16e4a9a"
},
{
"name": "client_id",
"value": "testopenid4"
},
{
"name": "user_id",
"value": "Unk"
},
{
"name": "datetime",
"value": "2019-03-06 03:04:09"
},
{
"name": "origin",
"value": "Authorize"
},
{
"name": "message",
"value": "2019-03-06 03:04:09 - 173.208.157.186 - Information : Authorize : Begin authentification for client = testopenid4\n\n"
},
{
"name": "level",
"value": "1"
},
{
"name": "weight",
"value": "1"
},
{
"name": "errnum",
"value": "110"
}
]
}
],
"objects": [
{
"id_oidc_log": "3400",
"remote_addr": "173.208.157.186",
"state": "",
"client_id": "testopenid4",
"user_id": "Unk",
"datetime": "2019-03-06 03:04:09",
"origin": "Authorize",
"message": "2019-03-06 03:04:09 - 173.208.157.186 - Information : Authorize : Begin\n\n",
"level": "1",
"weight": "0",
"errnum": "1"
},
{
"id_oidc_log": "3401",
"remote_addr": "173.208.157.186",
"state": "fc06ce8d03c189c7af1167d2e16e4a9a",
"client_id": "testopenid4",
"user_id": "Unk",
"datetime": "2019-03-06 03:04:09",
"origin": "Authorize",
"message": "2019-03-06 03:04:09 - 173.208.157.186 - Information : Authorize : Begin authentification for client = testopenid4\n\n",
"level": "1",
"weight": "1",
"errnum": "110"
}
]
}
}

Télécharger

Format json
Retourne un simple array. Exemple : la requête :

https://oa.dnc.global/web/http.api/json/oidc_logs/?offset=3000&length=2

retourne les mêmes éléments sous une forme très compacte :

[
{"id_oidc_log":"3400","remote_addr":"173.208.157.186","state":"","client_id":"testopenid4","user_id":"Unk","datetime":"2019-03-06 03:04:09","origin":"Authorize","message":"2019-03-06 03:04:09 - 173.208.157.186 - Information : Authorize : Begin","level":"1","weight":"0","errnum":"1"}
,
{"id_oidc_log":"3401","remote_addr":"173.208.157.186","state":"fc06ce8d03c189c7af1167d2e16e4a9a","client_id":"testopenid4","user_id":"Unk","datetime":"2019-03-06 03:04:09","origin":"Authorize","message":"2019-03-06 03:04:09 - 173.208.157.186 - Information : Authorize : Begin authentification for client = testopenid4",
"level":"1","weight":"1","errnum":"110"}
]

Télécharger

Le format collectionjson est intéressant en lecture. En écriture, on préférera le format json qui suffit à décrire les objets à enregistrer.

Actions

Suivant le paradigme HTTP Rest, les actions découlent de la méthode HTTP utilisée pour appeler l'API : get, post, put ou delete.

Formes générales des requêtes GET

Afficher la liste des collections disponibles sous le format indiqué :

https://oa.dnc.global/web/http.api/

Liste le contenu de la collection "type" :

https://oa.dnc.global/web/http.api//

Liste les éléments sélectionnés à l'aide des paramètres d'URL indiqués :

https://oa.dnc.global/web/http.api//?

Accès à une ressource précise :

https://oa.dnc.global/web/http.api/collectionjson//NN

NN est la valeur de l'identifiant (champ id_type, clé unique) de l'enregistrement dans la table.

Requêtes avec POST, PUT et DELETE

Ces requêtes doivent être générées programmatiquement : par exemple avec cURL côté serveur ou en Javascript côté client. On trouve couramment des bibliothèque exposant des fonctions de ce type :

post_collection($requete, $reponse)
Créer une nouvelle ressource dans la collection (créer un nouvel enregistrement dans la table).

put_ressource($requete, $reponse)
Ce cas est sensiblement le même que le précédent, à ceci près que l'on travaille sur la modification d'une ressource précise.

delete_ressource($requete, $reponse)
Supprimer définitivement une ressource.

Pour la transmission des données aux requêtes avec POST et PUT, deux formats sont possibles :
application/json :

$data = array(
'client_id' => 'testtest',
'client_secret' => 'TheBigSecret',
'redirect_uri' => 'https://oa.dnc.global/web/?action=oauth',
'grant_types' => 'authorization_code',
'scope' => 'openid sli',
);
$h = curl_init("https://oa.dnc.global/web/http.api/json/clients/");
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_POST, true);
$data_string = json_encode($data);
curl_setopt($h, CURLOPT_POSTFIELDS, $data_string);
curl_setopt($h, CURLOPT_HTTPHEADER, array(
'Content-Type: application/json',
'Content-Length: ' . strlen($data_string),
'Accept: application/json')
);

Télécharger

application/x-www-form-urlencoded :

...
curl_setopt($h, CURLOPT_HTTPHEADER, array(
'Content-Type: application/x-www-form-urlencoded',
'Accept: application/json')
);
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data));

Télécharger

Actions possibles

Toutes les combinaisons format/type/action ne sont pas disponibles.

En premier lieu, l'accès à l'API est subordonné à l'authentification de l'application cliente et de l'utilisateur final par OAuthSD.

Ensuite, toutes les combinaisons type/action ne sont pas autorisées. Des droits sont définis pour chaque action en fonction du profil de l'auteur (administrateur d'applications) authentifié.

Enfin, certaines actions ne sont pas (ou pas encore) implémentées.

Protection des données

Les données très sensibles (conditionnant la sécurité de l'authentification) sont protégées, elles ne peuvent être vues ni a fortiori modifiées à l'aide de l'API.

Dans l'état actuel, les champs suivants, définis par la constante API_HTTP_CHAMPS_SENSIBLES, ne sont pas transmis : client_secret, client_ip, password'.

clients (Applications clientes)

Requêtes GET

Le type clients permet de nombreuses requêtes GET avec les formats collectionjson et json, notamment avec les paramètres offset et length. La requête suivante est pratique pour générer des tableaux paginés :

https://oa.dnc.global/web/http.api/collectionjson/clients/?offset=100&length=10

Pour assurer la sécurité de l'authentification :
les donnée sensibles "client_secret" et "client_ip" ne seront pas retournées,
les paires de clés publiques/privées associées ne peuvent être atteintes,

Edition : requêtes POST, PUT, DELETE

Exemple d'écriture d'un nouvel enregistrement en PHP avec cURL. Les données sont transmises au format application/x-www-form-urlencoded [2] :

$data = array(
'client_id' => 'testtest',
'client_secret' => 'TheBigSecret',
'redirect_uri' => 'https://oa.dnc.global/web/?action=oauth',
'grant_types' => 'authorization_code',
'scope' => 'openid sli'
);
$h = curl_init("https://oa.dnc.global/web/http.api/json/clients/");
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_HTTPHEADER, array('
Content-Type: application/x-www-form-urlencoded'),
'Accept: application/json'
);
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data));
$res = curl_exec($h);
...

Télécharger

En HTML cela équivaudrait à :

$data = array(
'client_id' => 'testtest',
'client_secret' => 'TheBigSecret',
'redirect_uri' => 'https://oidc.dnc.global/web/?action=oauth',
'grant_types' => 'authorization_code',
'scope' => 'openid sli'
);
?>
foreach ( $data as $name => $value ) { ?>
echo $name;?>" name=" echo $name;?>" value=" echo $value;?>">
} ?>

Télécharger

En cas de succès, la table clients est mise à jour et l'API retourne dans le corps de la réponse un array Json avec le client_id et l'id_client (index unique de la table clients) :

{"
client_id":"testtest",
"id_client":43
}

Télécharger

En cas de duplication, la réponse suivante est retournée :

{
"collection": {
"version": "1.0",
"href": "https://oa.dnc.global/web/http.api/json/clients/",
"error": {
"title": "Erreur",
"code": 500
},
"errors": [
{
"title": "Erreur SQL 1062 Duplicate entry 'testtest' for key 'client_id'",
"code": 500
}
]
}
}

Télécharger

users (Utilisateurs finaux)

Le type users permet de nombreuses requêtes GET avec les formats collectionjson et json, notamment avec les paramètres offset et length. La requête suivante est pratique pour générer des tableaux paginés :

https://oa.dnc.global/web/http.api/collectionjson/users/?offset=100&length=10

Notez que la donnée sensible "password" ne sera pas retournée.

Enregistrement d'un utilisateur final sur le serveur OIDC

Le type users permet l'écriture (requêtes POST, PUT et DELETE).

Pour fonctionner, le contrôleur Authorize du serveur serveur OIDC n'a besoin que d'un username (ou d'un e-mail) et d'un mot de passe. Le contrôleur exploite également le contenu des autres champs fournis s'ils existent dans la table users et ne sont pas nuls.
En particulier, le champ scope peut être utilisé pour transmettre des autorisations propres à l'utilisateur.

Pour assurer la sécurité de l'authentification :
lors de l'écriture, le secret client transmis en clair est enregistré sous forme de password_hash avec l'algorithme PASSWORD_BCRYPT.

auteurs (Administrateurs d'applications ou "superviseurs")

oidc_logs (événements)

Le type oidc_logs n'autorise que les requêtes suivantes, sous les formats json et collectionjson :

Les événements étant triés par date décroissante, retourne length evenements depuis le rang 0 (donc les derniers événements) :

https://.../http.api//oidc_logs/?length=

Les événements étant triés par date décroissante, retourne length evenements depuis le rang offset :

https://.../http.api//oidc_logs/?offset=&length=

Les événements étant triés par date décroissante, retourne length événements autour du plus proche du temps indiqué par le timeserial ts :

https://.../http.api//oidc_logs/?ts=&length=

Retourne les évènements entre les timeserials tmin et tmax :

https://.../http.api//oidc_logs/?tmin=&tmax=

Notes :
Il est interdit de lister l'ensemble de la collection.
length est limité à 10000, sans génération d'erreur.

Sécurisation de l'accès à l'API

Deux configurations sont envisagées :
Le serveur qui porte l'API est accessible uniquement par des applications de confiance à travers un canal sûr (par exemple au sein d'un réseau local d'entreprise bien isolé). Dans ce cas, la constante API_HTTP_AUTHENTICATE est fixée à 'false' et des vérifications simples sont effectuées sur l'IP et/ou le domaine du client origine de la requête. Les constantes API_HTTP_CLIENT_IP et API_HTTP_CLIENT_HOST définissent les valeurs attendues.
Le serveur se trouve sur un réseau public. Dans ce cas, la constante API_HTTP_AUTHENTICATE est fixée à 'true' et l'application cliente doit s'authentifier avec le protocole OAuth 2.0. Pour ce faire, l'application cliente devra être enregistrée sur ce ce serveur OAuthSD avec les flux Authorization Code et Client Credentials. Notez que les contraintes définies par les constantes API_HTTP_CLIENT_IP et API_HTTP_CLIENT_HOST s'appliquent également.

Lorsqu'une application cliente veut accéder à l'API au nom d'un utilisateur final :
l'application authentifie son utilisateur final avec le flux Authorization Code,
si l'utilisateur final est authentifié, et seulement dans ce cas, l'application demande une autorisation d'accès en son nom propre avec le flux Client Credentials, puis passe le jeton d'accès obtenu dans l'appel à l'API,
l'API vérifie le jeton d'accès par introspection.

En fait, l'API peut aussi bien valider un jeton d'accès qu'un jeton d'identification. L'application cliente peut donc s'authentifier directement avec le jeton d'identité obtenu avec le flux Authorization Code.

Lorsqu'une application cliente veut accéder à l'API en son nom propre :
l'application demande une autorisation d'accès avec le flux Client Credentials, puis passe le jeton d'accès obtenu dans l'appel à l'API,
l'API vérifie le jeton d'accès par introspection.

Le jeton peut être passé à l'API sous le nom 'token' par les méthode POST ou GET, mais il est recommandé d'utiliser la méthode Auth Bearer.

Options

Les options suivantes sont définies dans le fichier collectionjsonoauthsd_options.php :

/* Cette API permet l'accès à la plupart des données manipulées par SPIP, les
types correspondant aux tables éponymes de la base de données. Cependant, autant
pour des raisons pratiques que de sécurité, les types servis sont limités à ceux
qui seront définis ici.
Si la chaine est '', tous les types seront autorisés.
Attention : le type est au singulier !*/
define('API_HTTP_TYPES_AUTORISES','oidc_log,user,client,auteur,credential') ;

/* S'agissant d'un serveur d'authentification, certaines données sont particulièrement
sensibles et doivent rester sanctuarisées.*/
define('API_HTTP_CHAMPS_SENSIBLES','client_secret,client_ip,password') ;

/* Si l'API doit être accessible autrement que par un client de confiance par
un canal sûr, il faut authentifier l'origine de la requête.
Cette constante peut aussi être fixée à false pendant le développement */
define('API_HTTP_AUTHENTICATE', false) ;

/* Si API_HTTP_AUTHENTICATE est fixé à true, l'authentification du client requiert
un jeton d'identité valide. Celui-ci contient la déclaration sub égale à l'id du
client (client_id). Si la constante suivante est non nulle, sub devra être égal à
la valeur indiquée. */
define('API_HTTP_CLIENT_ID', '') ;

/* Si API_HTTP_AUTHENTICATE a été fixé à false, il convient d'appliquer tout ou
partie des vérifications suivantes : */
define('API_HTTP_CLIENT_IP', '') ; // Vérifier que la requête vient de l'IP indiquée si non nulle
define('API_HTTP_CLIENT_HOST', '') ; // Vérifier que la requête vient du host indiqué si non nul

/* Si la requête ne définit pas le paramètre limit, les requêtes acceptant le
paramètre limit utiliseront la valeur suivante par défaut :*/
define ('API_DEFAULT_LENGTH', 100) ;

/* Nombre maximum de lignes que peut retourner une requête (dans le cas où le paramètre
limit n'est pas requis, comme quand la requête n'accepte que les paramètres tmin et/ou tmax) :*/
define ('API_MAX_ITEMS_RETURNED', 1000) ;

Utilisation de l'API par OAuthSD lui-même

OAuthSD utilise l'API notamment pour :
La présentation des événements : charger les données de la table oidc_logs avec Ajax pour les présenter en scrolling continu. Voir le tableau de la page Statistiques.
Permettre la supervision du serveur par une application extérieure.

[1] En réalité ce n'est pas équivalent. Voir : http://restcookbook.com/HTTP%20Methods/put-vs-post/

[2] Un intérêt de ce format est de permettre de transmettre l'identifiant de session du debugger

Extension pour Wordpress "OpenID Connect Generic Client"

DnC — 2019-05-10T15:17:07Z

Il existe différentes extensions de client OpenID Connect pour WordPress. Nous présentons ici OpenID Connect Generic Client de daggerhart qui nous parait complète, bien construite et bien documentée.

En cours de développement : un fork incluant le monitoring et le management de la session.

Installation

L'extension peut être trouvée sur GitHub :
https://github.com/daggerhart/openid-connect-generic,
https://github.com/bdegoy/openid-connect-generic (notre fork).
Le plugin s'installe comme toute extension, de façon classique ou avec Composer. Voyez la documentation.

Notes :
La source Github est mieux tenue à jour que celle du site WP (version testée jusqu'à 5.1.1 en mai 2019).

Inscription de l'application sur le serveur OAuthSD

Il s'agit des étapes 1 et 2 de la procédure décrite ici : OpenID Connect : Lier une application cliente au serveur OAuthSD.

S'inscrire en tant qu'auteur

En suivant cette procédure vous commencerez par vous inscrire en tant qu'auteur sur le serveur OAuthSD.

Inscrire l'application
Vous devez désigner votre application WordPress comme client du serveur OpenID Connect. Pour cela, accédez à l'URL : https://oa.dnc.global/web/?page=cre... :

Client Id : Entrez un nom court, sans espace ni caractère spécial autre que '_'. Ce n'est lié à aucune désignation de votre application.

Client secret (obligatoire) : une courte chaîne assimilable à un mot de passe fort. Ce code doit rester secret.

Redirect uri (obligatoire) : URI de retour à l'application cliente. Si l'URL de votre application WP est "http://votre_application.ext", inscrivez "http://votre_application.ext/wp-admin/admin-ajax.php?action=openid-connect-authorize.

Grant Type (obligatoire) : sélectionnez "Authorization Code".

Scopes (obligatoire) : Inscrivez "openid profile email".

Configuration de WP

Il s'agit de l'étape 3 de la procédure.

Accédez au menu Réglages -> OpenID Connect Client.

Votre application Wordpress doit être configurée comme ci-après, où Client ID et Client Secret Key sont les valeurs inscrites précédemment sur le serveur :

Inscription d'un utilisateur sur OAuthSD

Le principe de l'inscription unique (Single Sign On, SSO) permet à un utilisateur de se connecter à différentes applications avec les mêmes identifiants (login, mot de passe ...).
Il faut donc d'abord inscrire un utilisateur sur OAuthSD (ou utiliser un utilisateur OAuthSD existant). Faire l'inverse (créer l'utilisateur sur votre application WP et l'inscrire sur le serveur OpenID Connect) irait à l'encontre du principe.

L'inscription d'un utilisateur se fait ici : https://oa.dnc.global/web/spip.php?...

Création de l'utilisateur par WP

Si l'utilisateur n'existe pas du côté WP, l'extension le créera.

Notes :
Si on tente de se loger avec un identifiant de l'utilisateur OIDC qui existe déjà pour un utilisateur WP, le plugin crée un utilisateur WP avec un identifiant incrémenté ; par exemple si le login est "admin", l'utilisateur WP d'identifiant "admin2" sera créé avec un rôle "abonné". Il appartiendra à l'administrateur du site WP de modifier éventuellement ce rôle.
Dans le cas où l'e-mail de l'utilisateur OpenID existe déjà pour un utilisateur WP différent, c'est OpenID qui est maître : le plus logique sera de changer l'identifiant de cet utilisateur WP pour celui de l'utilisateur OpenID (puisque l'e-mail désigne une personne de façon non ambiguë).

Erreurs provenant de la configuration

Missing state - La plupart du temps, cette erreur provient du fait que l'utilisateur a été trop long pour s'identifier, ou est retourné sur un formulaire ancien. Il suffit de recommencer.

User claim incomplete - Se produit quand la liste des déclarations (claims) retournées par Userinfo, en fonction des portées définies pour l'application (scopes) ne contient pas celles qui sont définies dans le format.
Par exemple :

l'application a été configurée sans le scope email (champ de configuration OpenID Scope) et le format Email Formatting est email.
Display Name Formatting a été fixé à name alors que ce champ est null dans le serveur OpenID pour l'utillisateur considéré et que le nom de l'utilisateur figure dans la déclaration family_name.

Failed user creation - Se produit le plus souvent quand WP tente de créer un nouvel utilisateur et que l'e-mail déclaré par l'utilisateur OIDC existe déjà du côté de WP.

redirect_uri_mismatch : The redirect URI provided is missing or does not match - Cette erreur est générée par le serveur OAuthSD en réponse à la requête au contrôleur Authorize. Elle se produit lorsque l'URL de retour (Redirect URI) enregistrée sur le serveur OAuthSD n'est pas conforme à ce qui est indiqué en bas du formulaire Réglages -> OpenID Connect - Generic Client. En particulier, OAuthSD impose le protocole de transfert sécurisé (https).

ERREUR : les cookies sont bloqués ou ne sont pas reconnus par votre navigateur. Vous devez activer les cookies pour utiliser WordPress. - Il est probable que vous ayez omis 'https://' dans la barre d'adresse.

Erreur CORS (visible dans le debugger du navigateur)
C'est une erreur très courante que de lancer l'application de test avec http:// au lieu de https://. Cela peut également conduirte à une erreur CORS :
"(index):1 Access to XMLHttpRequest at 'https://oa.dnc.global/authorize?response_type=code&client_id=wpdemo&user_id=wpadmin&state=124979a12478&scope=openid&prompt=none' from origin 'http://wp.dnc.global' has been blocked by CORS policy : The 'Access-Control-Allow-Origin' header has a value 'https://wp.dnc.global' that is not equal to the supplied origin."

Démonstration

https://wp.dnc.global/2019/05/11/ex... est un démonstrateur d'une application WP liée à OAuthSD avec cette extension.

Monitoring : développement en cours

Nous développons un fork qui inclut le monitoring.
Le code est visible ici : https://github.com/bdegoy/openid-co.... Le fonctionnement est semblable à ce qui a été décrit pour Plugin OpenID Connect Client pour SPIP.

Plugin OpenID Connect Client pour SPIP

DnC — 2019-04-26T07:46:14Z

Un client OIDC pour SPIP. Permet à une application SPIP de proposer l'authentification avec OpenID Connect, à côté de l'authentification classique.

Les développeurs d'application SPIP pourront renforcer la protection de l'accès aux fonctionnalités réservées et à l'espace privé en limitant l'accès aux seules personnes enregistrées sur le serveur OIDC configuré [1].

Prérequis

v 1.0.3 : SPIP 3.0, 3.1 ; v 1.0.4 : SPIP 3.2,
système Linux + PHP 5.6 ou 7.1,
ionCube PHP Loader installé sur le serveur de l'application SPIP (IonCube est installé par défaut sur la plupart des configurations Linux).
Attention ! le fonctionnement d'OIDC exige une application cliente installée sur un serveur sécurisé (protocole https://).

Inscription de l'application sur le serveur OAuthSD

L'application recevant le plugin doit être enregistrée en tant que client du serveur OAuthSD.
La procédure est décrite ici : OpenID Connect : Lier une application cliente au serveur OAuthSD.

En suivant cette procédure :
vous vous inscrirez en tant qu'auteur sur le serveur OAuthSD,

vous enregistrerez votre application. L'enregistrement se fait ici : Inscrire une application cliente.
Vous devrez :

configurer l'adresse de retour (Redirect URI) sous la forme suivante : https://mon_application.com/?action=auth
Inscrire au moins le scope "openid".

l'installation et la configuration du plugin répond à l'étape 3 :

Installation et configuration du plugin

Le plugin se trouve sur GitHub :
https://github.com/bdegoy/oidcclient

Le plugin s'installe selon la procédure d'installation manuelle de tout plugin SPIP :

transférer le répertoire oidcclient dans le répertoire plugins,
activer le plugin dans l'administration.

ouvrir le formulaire de configuration et indiquer l'ID de l'application cliente et son secret fournis lors de l'enregistrement de l'application sur le serveur OAuthSD :

Inscription en tant qu'utilisateur OpenID Connect

Pour enregistrer votre application, vous vous êtes inscrit sur ce serveur en tant qu'auteur. Pour utiliser le SSO OpenID Connect [2], vous devez vous inscrire en tant qu'utilisateur sur un serveur d'authentification compatible. Les deux inscriptions sont distinctes.

Si vous n'êtes pas déjà inscrit sur OAuthSD, vous devez vous s'inscrire sur ce serveur en tant qu'utilisateur.

Il faut ensuite établir une correspondance entre OpenID Connect et SPIP.

Correspondance entre l'utilisateur OpenID Connect et l'auteur (l'utilisateur) SPIP

Si vous tentez la connexion OpenID Connect avec un utilisateur inconnu de l'application, vous obtiendrez un message d'erreur comme celui-ci :

Il faut que l'utilisateur OpenID Connect soit lié à un compte d'auteur de l'application SPIP pour que celle-ci accepte la connexion. Ceci est réalisé en inscrivant le login OIDC dans le champ oidc de la fiche de l'auteur.

Bien entendu, pour faire cette modification, vous devrez fournir le mot de passe du compte d'auteur [3] :

Notes :
On pourrait imaginer de créer un compte SPIP avec le même login, mais cela n'est pas nécessaire.
On pourrait également penser à une autre solution : créer un nouvel utilisateur OpenID Connect avec le login SPIP ; Mais cela irait à l'encontre du principe de connexion unique (SSO) : si un utilisateur a une inscription sur OAuthSD, c'est pour pouvoir se connecter à différents systèmes avec les mêmes identifiants. La bonne solution est donc de lier un auteur SPIP à un compte OIDC pré-existant, non l'inverse.
Dans certaines applications, il peut être opportun de créer automatiquement l'utilisateur manquant. Il existe en développement une version du plugin réalisant cela. Cette façon de procéder est sûre si l'inscription préalable de l'utilisateur sur le serveur OIDC est suffisamment contrôlée au regard des exigences de sécurité de l'organisation.

Une fois liés les utilisateurs OpenID Connect et SPIP, le formulaire de connexion fait apparaître le lien et propose la connexion avec OIDC :

Dans cette situation, il reste possible de se connecter "normalement" en actionnant le lien "Ne pas utiliser OIDC, utiliser un mot de passe".

Notes :
Un seul utilisateur OpenID Connect peut-être lié à un compte d'auteur de l'application SPIP. De même, un seul compte d'auteur de l'application SPIP peut être lié à un même utilisateur OpenID Connect.
Seul les logins servent à établir la correspondance, les mots de passe sont propres à chaque système.

Connexion à l'application SPIP

Le plugin modifie le cadre de connexion de SPIP en ajoutant la possibilité d'utiliser OpenID Connect. La méthode classique reste disponible :

Entrez votre email ou votre signature (pseudo) puis :

Pour vous identifier avec OpenID Connect, assurez-vous que le champ "Mot de passe" est vide et actionnez le bouton "Valider".

Pour vous connecter avec la méthode standard, entrez le mot de passe d'auteur (ou utilisateur) SPIP avant d'appuyer sur le bouton "Valider".

Notes :
Le plugin ajoute 'oidcclient' à la liste des méthodes disponibles (variable $GLOBALS['liste_des_authentifications']). SPIP tente les différentes méthodes d'authentifications enregistrées en commençant par la méthode standard. En cas d'échec, SPIP passe à la méthode suivante.
Si vous vous connectez avec la méthode standard, et que votre login ou mot de passe est faux, vous serez redirigé vers la connexion avec OpenID Connect. Dans cette situation, la fonctionnalité SLI pourrait aboutir à une connexion automatique.
Si votre navigateur vous propose de mémoriser les identifiants de connexion, il est inutile de le faire : le mot de passe vu par le navigateur est crypté et change à chaque fois.

Monitoring

Le monitoring de l'état de l'authentification a pour but de synchroniser la connexion locale d'une application avec le jeton d'accès correspondant. Il permet notamment de visualiser l'état de connexion de l'utilisateur :

icône	Signification
	La connexion de l'utilisateur final n'est pas établie avec le serveur OIDC. Notez que l'utilisateur peut s'être connecté à l'application à l'aide de la méthode de connexion classique de SPIP.
	L'utilisateur final et l'application sont connectés par OIDC.
	Erreur générale, traduit malheureusement de multiples situations : perte de communication Internet, défaut de configuration du plugin, défaut d'inscription de l'application cliente sur le serveur OAuthSD, inscription de l'application sur un autre serveur, non compatible OAuthSD, login inconnu du serveur OAuthSD (l'utilisateur final n'est pas inscrit sur ce serveur), etc. Le message peut éventuellement être plus explicite : "authentication error", ... Notons que l'icône erreur peut apparaître brièvement au changement de page.

Le Monitoring permet également de manager la session OIDC et notamment d'effectuer la déconnexion globale (SLO).
En cliquant sur l'icône, des popups apparaissent selon l'état de connexion :

Une fonctionnalité du monitoring consiste à alerter l'utilisateur de la fin imminente de la session OIDC et lui permettre de la prolonger :

Notons que le monitoring a besoin pour fonctionner d'être appelé à partir d'un bloc div dans toutes les pages de votre application, par exemple dans le pied de page :

SPIP

[(#REM) Monitoring OAuthSD]

Pour plus d'information sur le monitoring voyez :
Monitoring de l'état de l'authentification et SLO
Avertir de la fin de session OIDC et la prolonger

Informations sur le serveur et la connexion OIDC

Un clic sur le point d'interrogation fait apparaître une fenêtre popup donnant les informations sur la connexion au serveur OIDC :

Serveur : l'URL du serveur OIDC, cliquez pour atteindre le site support du serveur.
Client ID : l'ID de l'application courante sur le serveur.
Login SPIP : l'identifiant de connexion de l'utilisateur à l'application SPIP. Nul si l'utilisateur n'est pas connecté.
Login OIDC : l'identifiant d'enregistrement de l'utilisateur sur le serveur OIDC (peut-être différent du précédent). Nul si l'utilisateur n'est pas connecté.
T. session restant : la durée de vie restante de la session OIDC.
Délai de réponse : durée de cycle de la dernière interrogation du contrôleur Authorize. Un temps anormalement long (supérieur à la seconde) peut traduire une connexion de données lente, une erreur de communication ou une surcharge du serveur OIDC. Si vous pensez que votre connexion de données est bonne, et si une durée anormalement longue persiste, contactez l'administrateur du serveur.

Commentaires et avertissements :

Ce plugin n'est pas un remplacement ou un équivalent du plugin OpenID.

Il reprend cependant le principe du plugin OpenID qui consiste à donner le choix entre la connexion avec OpenID Connect ou la méthode login/mot de passe classique. Merci aux auteurs d'OpenID à qui a été emprûntée la structure générale du plugin.

OpenID Connect (OIDC) ne doit pas être confondu avec OpenID. La connexion automatique avec un identifiant OpenID universel n'existe pas dans le standard OIDC. OIDC offre une sécurité supérieure en permettant de construire un système propriétaire dans lequel les applications clientes et les serveurs, ainsi que les utilisateurs, sont limités à un ensemble bien identifié.

Un utilisateur qui souhaite utiliser OIDC pour s'identifier doit être enregistré sur un serveur OIDC que lui a désigné le concepteur de l'application et dont l'URL est configurée dans l'administration de ce plugin.

Un concepteur d'application qui utilise ce plugin doit enregistrer l'application en tant que client sur un serveur OpenID Connect.

Si vous voulez le faire sur ce serveur OAuthSD, il faut vous inscrire comme auteur et administrateur d'applications puis enregistrer l'application.

La version du plugin présentée ici date un peu. Depuis, une nouvelle version a été développée et abondamment testée avec les applications i-Tego SaaS. Il est notamment possible de pratiquer la connexion automatique.

Ce site web implémente un démonstrateur d'OAuthSD ; le serveur peut être indisponible et les données enregistrées effacées à tout moment.

Aucune garantie d'aucune sorte n'est attachée à l'utilisation de ce serveur, des plugins, du code et de la documentation fourni par i-Tego.

Le plugin est distribué sous licence GPL3.

une partie sensible du source du plugin n'est pas fournie pour des raisons de sécurité.

FAQ

Erreur :
Le login OIDC xxx n'est pas lié à un compte de cette application.

Cette erreur apparaît après que vous avez validé le formulaire d'identification (ou en cas de connexion automatique à une nouvelle application). Elle signifie que le login que vous avez indiqué dans ce formulaire (ou le login indiqué par le cookie en cas de reconnexion automatique) n'est pas un login d'auteur de l'application SPIP à laquelle vous avez tenté de vous connecter. Reportez-vous au paragraphe "Correspondance entre l'utilisateur OpenID Connect et l'auteur (l'utilisateur) SPIP " ci-dessus.

Un conseil : faites simple, créez le login SPIP ou modifiez-le de façon à ce qu'il soit identique au login OIDC.
Important : Ne créez pas un nouvel utilisateur OpenID Connect avec le login SPIP, cela est contraire au principe même de l'inscription unique (Single Sign On, SSO).

Question :
Quelle différence entre le lien "Se déconnecter" et "Clore la session OpenID Connect" ?

Cela dépend de la façon dont le lien "Se déconnecter" a été écrit par le développeur de l'application SPIP :
si le lien contient le paramètre d'URL "logout=public", les deux méthodes sont équivalentes et conduiront à la déconnexion globale : toutes les applications actuellement connectées pour l'utilisateur authentifié seront déconnectées et la session OpenID Connect sera détruite ;
si le lien contient le paramètre d'URL "logout=local", seule l'application courante sera déconnectée, la session OpenID Connect étant préservée.

Notes :
Le plugin surcharge la fonction action_logout_dist(). Par défaut, toute utilisation de cette fonction, sans préciser le paramètre d'URL "logout=local" générera une demande de déconnexion vers OIDC.
Il est peut-être préférable de na pas préciser "logout=local" afin de provoquer systématiquement la déconnexion globale, ce qui va dans le sens de la sécurité, particulièrement si une application est restée connectée sur un mobile ou une autre station de travail.

Question :
Et tout cela fonctionne avec un mobile ?
Oui, bien sûr, et pourquoi pas ?
En particulier, le mobile obéira bien à une déconnexion globale venant d'une autre application.

Question :
Est-ce que fermer le navigateur suffit à provoquer une déconnexion globale ?
Non.
Il faut explicitement clore la session OIDC.
D'ailleurs, si vous relancez le navigateur sur l'application que vous venez de quitter alors qu'elle était connectée, elle sera aussitôt reconnectée.
Il en est de même si on se contente de fermer l'onglet du navigateur dans lequel l'application était lancée et connectée.

[1] Pour l'instant, ce plugin n'a été validé que sur le serveur OAuthSD (ce serveur).

[2] Ne pas confondre avec OpenID

[3] Y compris si l'opération est effectuée par l'administrateur, afin de protéger parfaitement les intérêts de l'utilisateur.

Stylage des formulaires d'identification

DnC — 2019-03-17T15:41:00Z

OAuthSD offre deux moyens d'apdater les formulaires à la charte graphique d'une organisation :
my.css féfinit les styles propres à une organisation, qui s'appliqueront à tous les clients inscrits sur le serveur,
le champ css de la table Clients sera éventuellement utilisé pour attribuer un stylage particulier à une application.

Structure générale des formulaires

Le corps des formulaires présente la structure HTML suivante :

...
="page" class="(le nom de la méthode)">
="top">>
="container">
="head-title"> ... >
...
="error"> ... >
...
>
="bottom">
...
>
>

Télécharger

Adaptation de la charte graphique

Styles par défaut

Par défaut, les styles des formulaires d'identification sont définis dans la section head de chacun d'eux.

Fichier my.css

S'il existe un fichier /my.css à la racine du serveur, celui-ci est adopté comme feuille de style.

Ce fichier pourra être utilisé pour insérer un logo de l'organisation. Le champ #top est sans doute bien adapté à recevoir une image en background.

Champ css de la table Clients

Qu'il s'agisse de la feuille de style ou du défaut, les styles peuvent être complétés ou surchargés par le contenu du champ css de la table clients. Dans l'exemple ci-dessous, la variable $thecss contient les données de ce champ.

Ces styles intervenant en final, ils l'emportent sur les précédents.

Exemple

Voici par exemple les définitions de styles du formulaire de login :

PHP

// Styles
$thecss = ( empty($data['css'])? '' : htmlspecialchars($data['css']) );
if ( file_exists('my.css') ) { //[dnc37]
$style = '" .';
if ( !empty($thecss) ) $style .= $thecss;
} else {
$style = '
';
}

Télécharger


Formulaire d'identification avec GhostKeys

Applications natives : un exemple avec Windev

DnC — 2019-01-14T13:22:25Z

Nous donnons ici un exemple d'une application Windows native réalisée avec Windev qui utilise l'authentification OpenID Connect.

Cette application met en oeuvre le flux d'autorisation avec code (Authorization Code Grant) d'OpenID Connect en passant par l'interface de bouclage (loopback) du réseau local.

Redirection par l'interface de bouclage du réseau

C'est l'une des trois méthodes décrites dans cet article : OAuth 2.0 (et OpenID Connect) pour les applications natives.

Traduction d'extraits de rfc8252 :

Les applications natives capables d'ouvrir un port sur l'interface de bouclage du réseau peuvent utiliser l'interface de bouclage du réseau pour recevoir la redirection OAuth.

Les URI de redirection de bouclage utilisent le schéma HTTP et sont construits avec l'adresse IP littérale de l'interface de bouclage et le port sur lequel le client écoute. C'est-à-dire http://127.0.0.1:{port‹/{path} pour IPv4 et http: // [:: 1]: {port} / {chemin} pour IPv6.

Exemple avec Windev WD OAuth

Depuis la version 24, Windev permet de réaliser une authentification via le protocole OpenID Connect [1] avec la composante wd240ggl.dll. Voir : Fonction AuthIdentifie.

Cette implémentation répond aux éléments de spécification présentés ci-dessus en employant comme il se doit le flux Authorization Grant (et non un flux implicite), en passant par l'interface de bouclage localhost, ainsi qu'un navigateur extérieur à l'application.

Nous avons modifié l'exemple didactique (WINDEV) WD OAuth pour intégrer une nouvelle classe OAuthSDLogin. Cette classe est absolument identique (au paramétrage près) à la classe GoogleLogin, ce qui prouve la totale compatibilité du serveur OAuthSD.

Ceci permet d'affirmer que toute application assurant l'authentification avec Google OpenID Connect pourra fonctionner avec OAuthSD, pourvu que les paramètres de connexion au serveur d'authentification puissent être modifiés pour adopter ceux d'OAuthSD.

WINDEV

// Classe OAuthSDLogin
// Gère l'authentification OpenID Connect via OAuthSD. Voir : https://oa.dnc.global/86
OAuthSDLogin est une Classe
hérite de OAuthAppLogin
FIN
PROCÉDURE Constructeur()
// Appel du constructeur OAuthAppLogin
Constructeur OAuthAppLogin("OAuthSD")
// Décrit l'application OAuth
// La clé et le code secret sont inscrits sur le serveur OAuthSD au moment de l'enregistrement de l'application.
m_oServiceOAuth..ClientID = "WindevOAuthSDLogin" // 'Client ID'
m_oServiceOAuth..ClientSecret = "uhkdfk7bUXWq!" // 'Client secret'
dbgVérifieDifférence(m_oServiceOAuth..ClientID, "", "ClientID non renseigné")
dbgVérifieDifférence(m_oServiceOAuth..ClientSecret, "", "ClientSecret non renseigné")
// Le flux OAuth 2.0 requiert des 'Scopes'
// "Space-delimited set of scope strings."
m_oServiceOAuth..Scope = "openid profile sli"
// Le flux OAuth 2.0 nécessite deux points d'accès :
// - un point d'accès pour authentifier l'utilisateur
// - un point d'accès pour l'obtention d'un 'AccessToken'
m_oServiceOAuth..URLAuth = "https://oa.dnc.global/authorize"
m_oServiceOAuth..URLToken = "https://oa.dnc.global/token"
m_oServiceOAuth..ParamètresSupplémentaires = "response_type=code" //
// L'URL de callback vers localhost permet à l'application de recevoir le code d'autorisation.
m_oServiceOAuth..URLRedirection = "http://localhost:9000/"
PROCÉDURE Destructeur()
// Résumé : Lit le profil utilisateur
// Syntaxe :
//[ = ] LectureProfilUtilisateur ()
//
// Paramètres :
// Aucun
// Valeur de retour :
// OAuthWebUser : Informations sur l'utilisateur
//
PROCÉDURE VIRTUELLE PROTÉGÉE LectureProfilUtilisateur()
clInfo est un OAuthWebUser
vInfo est un Variant
oRequête est une httpRequête
oRéponse est une httpRéponse
oRequête..URL = "https://oa.dnc.global/userinfo"
oRequête..AuthToken = m_oToken
oRequête..Méthode = httpGet
// Exécute la requête permettant d'obtenir les informations du profil de l'utilisateur connecté
oRéponse <- HTTPEnvoie(oRequête)
SI PAS ErreurDétectée _ET_ PAS oRéponse..CodeEtat >= 400 ALORS
// Décode la réponse JSON contenu dans le message
vInfo = JSONVersVariant(oRéponse..Contenu)
// Recopie les données lues
// Attention, les chaînes sont au format ANSI / UTF-8
// Pour les afficher, il est nécessaire d'utiliser AnsiVersUnicode(, alphabetUTF8)
clInfo.ID = vInfo.id
clInfo.Nom = vInfo.name
clInfo.NomAffiché = vInfo.given_name
clInfo.Image = vInfo.picture
clInfo.Email = vInfo.email
FIN
RENVOYER clInfo

Télécharger

Dans le paramétrage de la demande d'autorisation, noter :
m_oServiceOAuth..Scope = "openid profile sli" : le scope openid entraîne l'utilisation du protocole OpenID Connect.
m_oServiceOAuth..ParamètresSupplémentaires = "response_type=code" qui entraîne la mise en oeuvre du flux Authorization Code Grant.

Comme d'habitude, le login est "bebert", le mot de passe "012345678"

Après login, l'exemple effectue l'échange des jetons puis une requête userinfo, dont le résultat, guère impressionnant, est cependant probant du bon fonctionnement :

On peut également vérifier le bon fonctionnement de la connexion unique (SLI) avec cette application.

[1] PC Soft nomme "OpenID" ce qui est en fait OpenID Connect.

Extension OpenID Connect pour phpBB

DnC — 2018-12-21T10:00:58Z

Un client OIDC pour phpBB. Permet à phpBB d'utiliser OpenID Connect au lieu de l'authentification classique. (Attention : à ne pas confondre avec les extension pour OpenID !)

Les développeurs d'application phpBB pourront faciliter l'intégration des forums dans leurs autres applications Web en permettant l'accès des utilisateurs avec une inscription unique configurée sur le serveur OIDC (Single Sign-On, SSO).

OAuthSD vous offre plus que l'inscription unique. La connexion unique (Single Login-In, SLI) : une fois connecté à une application, vous serez connecté de manière transparente aux autres (à condition bien sûr qu'elles soient enregistrées sur le serveur).

Prérequis

phpBB 3.x
système Linux + PHP 5.6 ou 7.1.
Attention ! le fonctionnement d'OIDC exige une application cliente installée sur un serveur sécurisé (protocole https://).

Inscription sur le serveur OAuthSD

L'application recevant l'extension doit être enregistrée sur le serveur OAuthSD [1].
La procédure est décrite ici : OpenID Connect : Lier une application cliente au serveur OAuthSD.

En suivant cette procédure :
vous vous inscrirez en tant qu'auteur sur le serveur,

vous enregistrerez votre application. L'enregistrement se fait ici : Inscrire une application cliente.
Vous devrez :

configurer l'adresse de retour (Redirect URI) sous la forme suivante : https://mon_application.com/ucp.php?mode=login&login=external&oauth_service=oauthsd
Inscrire les scopes "openid sli".

Notez les valeurs de "Client id" (qui correspondra à "Key" dans phpBB) et "Client secret".

Installation et configuration sur phpBB

1. Le client OIDC pour phpBB s'installe comme toute extension de phpBB :
télécharger l'extension OIDC client for phpBB (se trouve aussi sur GitHub),
décompresser l'archive,
installer le code dans /ext/bdegoy/oauthsd,
dans phpBB, installez l'extension "DnC OIDC client for OAuthSD" (section Customize -> Extension Manager).

2. Installez le service OAuthSD pour Lusitanian / PHPoAuthLib :
phpBB utilise la bibliothèque Lusitanian / PHPoAuthLib pour mettre en œuvre le SSO avec OIDC. Nous devons compléter cette bibliothèque avec le service Oauthsd. Le service OAuthSD est fourni avec le fichier ... /oauthsd-phpbb/OAuth/OAuth2/Service/Oauthsd.php qui doit être copié dans le répertoire .../vendor/lusitanian/oauth/src/OAuth/OAuth2/Service/.

3. dans phpBB, section Client Communication -> Authentication, sélectionnez la méthode d'authentification Oauth :

Entrez les paramètres pour OAuthSD :

puis actionnez le bouton "Submit".

Si tout s'est bien passé, un bouton "OAuthSD" doit apparaître dans la page de Connexion :

Notes :
Le bouton "OAuthSD" n'apparait pas partout où la connexion est possible. Par exemple, on s'attendrait à voir le bouton sur la page de connexion à l'administration, mais ce n'est pas le cas. Cela dépend de phpBB [2], pas de l'extension.

phpBB : Tentative de connexion avec un compte inconnu du forum

Si on tente de se connecter avec un login (un "Nom d'utilisateur" dans le vocabulaire phpBB) qui n'est pas enregistré sur le forum, phpBB signale l'erreur :

il est proposé de :
lier le compte à un compte existant : Entrer le Nom d'utilisateur et le Mot de passe puis actionner "Connexion" [3]
créer un nouveau compte : Actionnez le bouton "S'enregistrer".

Notes :
Seul le login (le Nom d'utilisateur) doit être identique des deux côtés, le mot de passe est propre à chaque système.
On pourrait penser à une autre solution : inscrire le compte phpBB sur le serveur d'authentification. Mais cela irait à l'encontre du principe de connexion unique (SSO) : si un utilisateur a une inscription sur OAuthSD, c'est pour pouvoir se connecter à différents systèmes avec les mêmes identifiants.

Feuille de route

Paramétrer l'URL du serveur OIDC afin de pouvoir choisir le serveur d'authentification. Cela devrait conduire à un client OpenID Connect universel.
Essayer d'agir sur phpBB pour mieux intégrer l'authentification. Par exemple, l'insertion du bouton d'authentification sur la page de connexion ACL.

En conclusion ...

Cette inscription d'une application PhpBB montre qu'OAuthSD est bien un serveur d'authentification tout aussi accessible que les grandes plateformes. Mais avec OAuthSD nous vous offrons beaucoup plus : le moyen de protéger vos données et de protéger les visiteurs de vos sites à l'aide d'un serveur de votre propriété.

Notons que cette utilisation qui est faite d'OpenID Connect réduit le point de vue au SSO. OpenID Connect, c'est énormément plus que le SSO, qui n'en est qu'un aspect mineur.

OpenID Connect, c'est :
la protection des mots de passe,
la sécurisation des échanges entre applications réparties dans le Cloud,
et, avec OAuthSD, la Connexion unique (Single Login-In, SLI)
etc.

Voyez :

https://area51.phpbb.com/docs/dev/3.2.x/extensions/tutorial_authentication.html

On GitHub
https://github.com/bdegoy/oauthsd-phpbb
Issues (Bug reports or feature request) :
https://github.com/bdegoy/oauthsd-phpbb/issues

[1] Dans l'état actuel du développement, l'extension ne permet que la connexion à ce serveur OAuthSD, cela n'est donc envisageable que dans une phase de développement. DnC propose à ses clients de posséder leur propre serveur OIDC afin de bénéficier de toute la sécurité offerte par un système d'authentification privé.

[2] La connexion à l'aide d'un système extérieur n'est gérée que dans le script ucp.php (User Control Panel) mais pas dans acp.php (Admin Control Panel).

[3] Si, ce faisant, vous liez l'utilisateur Oauth à un utilisateur phpBB qui avait déjà été lié, vous obtenez une erreur SQL du genre "Duplicate entry '2-oauthsd' for key 'PRIMARY' [1062]", où "2" est l'ID de l'utilisateur phpBB . C'est un bug de phpBB qui devrait auparavant effacer l'entrée user_id = 2 dans la table phpbb_oauth_account. Si on efface manuellement cette entrée, on peut terminer l'opération.

OpenID Connect OAuth Server dédié

APACHE mod_auth_openidc

Préparation

Configurer un VirtualHost

Déclarations renvoyées depuis OpenID Connect via le module Apache

Autorisation Apache Require

Principes et organisation générale d'un déploiement OpenID Connect

Principes auxquels doivent se conformer les applications

Implémentation du monitoring avec Javascript : exemples pour SPIP et WordPress

Implémentation du monitoring dans le plugin OpenID Connect client pour SPIP

Implémentation du monitoring dans une extension Wordpress

API HTTP REST + TreeQL

Sécurisation de l'accès à l'API et transmission du rôle de l'utilisateur final

Limitation de l'accès aux tables et aux champs

Opérations CRUD + List : Référence de l'API

Sélections avancées

Filtres

Filtres multiples

Sélection de colonne

Tri

Taille limite

Pagination

Jointures

Opérations par lots

API HTTP REST

Types

Formats

Actions

clients (Applications clientes)

users (Utilisateurs finaux)

auteurs (Administrateurs d'applications ou "superviseurs")

oidc_logs (événements)

Sécurisation de l'accès à l'API

Options

Utilisation de l'API par OAuthSD lui-même

Extension pour Wordpress "OpenID Connect Generic Client"

Installation

Inscription de l'application sur le serveur OAuthSD

Configuration de WP

Inscription d'un utilisateur sur OAuthSD

Création de l'utilisateur par WP

Erreurs provenant de la configuration

Démonstration

Monitoring : développement en cours

Plugin OpenID Connect Client pour SPIP

Prérequis

Inscription de l'application sur le serveur OAuthSD

Installation et configuration du plugin

Inscription en tant qu'utilisateur OpenID Connect

Correspondance entre l'utilisateur OpenID Connect et l'auteur (l'utilisateur) SPIP

Connexion à l'application SPIP

Monitoring

Informations sur le serveur et la connexion OIDC

Commentaires et avertissements :

FAQ

Stylage des formulaires d'identification

Structure générale des formulaires

="head-title"> ... >

Adaptation de la charte graphique

Applications natives : un exemple avec Windev

Redirection par l'interface de bouclage du réseau

Exemple avec Windev WD OAuth

Extension OpenID Connect pour phpBB

Prérequis

Inscription sur le serveur OAuthSD

Installation et configuration sur phpBB

phpBB : Tentative de connexion avec un compte inconnu du forum

Feuille de route

En conclusion ...

Voyez :