Choisissez un exemple OAuth pour votre serveur, votre application native ou votre navigateur.
Commencez après création de l’application. Tous les exemples utilisent le code d’autorisation avec PKCE S256 et lisent seulement le profil connecté.
| Exemple | Langages | Contenu |
|---|---|---|
| OAuth côté serveur | TypeScript / Node.js 24, Python 3.11+ | Fonctions pour consentement, retour, API, renouvellement et révocation |
| Native / bureau | JavaScript / Node.js 24, Python 3.11+ | Démos exécutables avec navigateur système et bouclage IP |
| Navigateur | JavaScript, TypeScript | Démo HTML avec client public et jeton en mémoire |
Les exemples utilisent des bibliothèques standard. Le backend nécessite les sessions et le stockage de votre framework. Les démos natives et navigateur s’exécutent après enregistrement et configuration. Ce sont des exemples pédagogiques, pas un SDK ni une application de production complète.
Vidéo : connecter et déconnecter un compte
Enregistrement sans son de l’application locale avec des comptes fictifs. L’interface est en anglais ; les sous-titres sont disponibles en anglais, allemand, français et néerlandais.
Cette vidéo utilise une application backend et un testeur accepté. Elle montre le consentement, un véritable échange de code et la révocation, mais pas une requête de données API. Les étapes de consentement et de déconnexion sont identiques pour les clients natifs et navigateur.
Télécharger la vidéo (WebM)
0:00 Un testeur accepté ouvre l’application tierce et choisit « Link your R+D account ».
0:08 R+D affiche l’identité de l’app et les permissions demandées. Vérifiez-les avant d’autoriser l’accès.
0:14 Choisissez « Allow selected permissions ». Le navigateur revient à l’adresse de retour de l’app.
0:19 Le serveur valide le retour et échange le code avec PKCE. Les jetons restent sur le serveur.
0:25 Pour consulter ou retirer l’accès, ouvrez les paramètres R+D → Applications connectées.
0:32 Choisissez « Disconnect ». L’app ne peut plus utiliser cette connexion pour accéder à l’API.
Échange commun
- Générez un état aléatoire et un vérificateur PKCE pour l’utilisateur à l’origine de la demande.
- Ouvrez
/oauth/authorizeavec ID client, retour exact, scope, état et challenge S256. - Consommez la transaction une seule fois ; vérifiez
stateetiss, même en cas de refus. - Envoyez code, retour et vérificateur à
/oauth/tokensous forme de formulaire. Le backend s’authentifie également. - Vérifiez les scopes accordés, puis envoyez le jeton Bearer aux opérations autorisées.
Configurez un émetteur fixe par environnement. Les métadonnées se trouvent dans
/.well-known/oauth-authorization-server ; ne choisissez jamais un endpoint de
jeton à partir d’un iss non validé. Les jetons sont opaques, sans ID token OpenID Connect.
Traiter les erreurs
Après access_denied, validez l’état et l’émetteur puis restez déconnecté. Refusez
les paramètres inattendus, dupliqués ou expirés sans échanger le code. Ne réutilisez
pas un code rejeté ; vérifiez PKCE, retour, environnement et authentification client.
Pour 401, renouvelez une fois si possible ou reconnectez ; pour 403, vérifiez
scopes et permissions de compte/appareil ; pour 429, respectez Retry-After.
Ne renvoyez jamais l’ancien jeton de renouvellement après un résultat ambigu.
Les jetons d’accès durent dix minutes. Les démos ne demandent pas offline_access.
La limite est de 60 appels API par minute, application et utilisateur. Consultez
la référence OAuth pour le cycle de vie complet.