Ceci suppose que le développeur ou son organisation soit inscrit sur le serveur en tant qu’Administrateur d’applications.
Le processus comporte deux aspects :
du côté du serveur OAuth, inscrire l’application,
du côté de l’application cliente, insérer le code nécessaire pour assurer le lien avec le serveur OAuth.
1. S’inscrire en tant qu’Administrateur d’applications
L’inscription se fait ici : Formulaire d’inscription.
Renseignez soigneusement votre fiche d’Administrateur d’application, la plupart de ces informations étant communiquées aux utilisateurs finaux dont vous devez gagner la confiance.
Attention : ne confondez pas l’inscription en tant qu’Administrateur d’applications (un développeur qui inscrit son application cliente pour qu’elle puisse déléguer l’authentification à OAuthSD) avec l’inscription d’un internaute en tant qu’utilisateur final des applications clientes, qui se fait ici : Je m’inscris.
Notes :
Le terme "Administrateur d’applications" permet de distinguer le développeur ou le propriétaire d’une application cliente qui s’inscrit sur ce serveur, de l’utilisateur final, qui doit aussi s’inscrire, mais autrement. Dans le modèle de données sous-jacent, il s’agit également de l’objet éditorial de SPIP (la table Auteurs), tandis que l’utilisateur final correspond à une table distincte.
2. Inscrire l’application cliente sur le serveur OAuthSD
Dans la rubrique Gérer, aller à Ajouter (Inscrire) une application cliente et remplir le formulaire :
Client Id (obligatoire) : Chaine identifiant l’application de façon unique. Entrez un nom court, sans espace ni caractère spécial autre que ’_’. Cet identifiant doit être unique pour tous les administrateurs d’applications inscrits sur le serveur. Il est visible du public et doit donc être représentatif de l’application et de votre entreprise.
Client secret (obligatoire) : une courte chaîne assimilable à un mot de passe fort. Ce code n’apparait que dans ce dialogue et doit rester secret.
Redirect uri (obligatoire) : URI de retour à l’application cliente. C’est l’adresse à laquelle le serveur OAuth fait retour sur le client avec le résultat de l’authentification.
Grant Type (obligatoire) : sélectionnez un des Types d’autorisation.
Scopes (obligatoire) : Liste des Scopes autorisés pour l’application, séparés par un espace. Dans une phase de test ou pour une application simple, si vous n’avez pas défini de scope, indiquez "basic".
User id ID de l’utilisateur unique de l’application. Utilisé notamment pour l’autorisation serveur à serveur. Laissez vide si votre application ne nécessite pas de définition de l’UserId.
Vérifiez vos entrées et actionnez le bouton "Enregistrer".
Vous pourrez retrouver l’application et la modifier à la rubrique Toutes vos applications clientes.
Enfin, naviguez à l’adresse https://oa.dnc.global/keys afin de créer l’entrée correspondant à la nouvelle paire de clés publique/privée.
Vous pourrez retrouver l’application et la modifier à la rubrique Toutes vos applications clientes.
Notes :
OAuthSD crée pour l’application cliente une paire de clés publique/privée. Si vous souhaitez la changer, allez à la rubrique Toutes vos applications clientes et sélectionnez l’action "clés" correspondant à l’application.
OAuth Server by DnC étant conforme à la spécification OAuth 2.0, toute application apte à déléguer ses autorisations à un serveur compatible OAuth 2.0 peut être inscrite sans modification sur OAuth 2 Server by DnC.
3. Insérer dans l’application le code nécessaire
Si l’application cliente est conçue pour déléguer ses authentifications à un serveur à la norme OAuth 2.0, il n’y a rien de plus à faire.
Sinon, c’est une affaire de développeur. Il y a deux adaptations à réaliser :
Écrire le code situé au Point d’extrémité de redirection, ou URI de retour à l’application cliente (Redirection Endpoint). Il s’agit de demander au serveur OAuth un jeton d’accès pour l’application, à partir du Code d’autorisation (Authorization code) retourné par le serveur. Nous en donnons un exemple ici : Exemple de code pour le Point d’extrémité de redirection.
Consommer une API protégée de type HTTP REST est extrêmement simple. Voici un exemple avec L’API REST de Radar : Une fonction pour tout simplifier !.
Notes :
OAuth Server by DnC étant conforme à la spécification OAuth 2.0, l’adaptation de l’application décrite ci-dessus lui permettra de déléguer ses autorisations à n’importe quel serveur compatible OAuth 2.0.
RSS 2.0