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 ethttp: // [:: 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 :
//[ <Résultat> = ] 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(<chaîne>, alphabetUTF8)
clInfo.ID = vInfo.id
clInfo.Nom = vInfo.name
clInfo.NomAffiché = vInfo.given_name
clInfo.Image = vInfo.picture
clInfo.Email = vInfo.email
FIN
RENVOYER clInfoDans 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.
OpenID Connect OAuth Server dédié
Plus de sécurité et de confidentialité avec un serveur d’authentification indépendant

