Wählen Sie OAuth-Beispiele für Backend, native Anwendungen oder Browser.
Beginnen Sie nach dem Erstellen der App. Alle Beispiele verwenden Autorisierungscode mit S256 PKCE und lesen nur das Profil des verbundenen Nutzers.
| Beispiel | Sprachen | Inhalt |
|---|---|---|
| Backend-OAuth | TypeScript / Node.js 24, Python 3.11+ | Framework-unabhängige Hilfsfunktionen für Zustimmung, Rückruf, API, Erneuerung und Widerruf |
| Native / Desktop | JavaScript / Node.js 24, Python 3.11+ | Ausführbare Demos mit Systembrowser und IP-Loopback |
| Browser | JavaScript, TypeScript | HTML-Demo mit öffentlichem Client und Token nur im Arbeitsspeicher |
Die Beispiele verwenden Standardbibliotheken. Backend-Beispiele benötigen die Sitzung und Speicherung Ihres Frameworks. Native und Browser-Demos laufen nach Registrierung und Konfiguration. Sie sind Lernbeispiele, kein SDK oder vollständiges Produktionssystem.
Video: Konto verbinden und trennen
Stumme Aufnahme der lokalen App mit fiktiven Konten. Die Oberfläche ist auf Englisch; Untertitel sind auf Englisch, Deutsch, Französisch und Niederländisch verfügbar.
Diese Aufnahme verwendet eine Backend-App und einen akzeptierten Tester. Sie zeigt Zustimmung, einen echten Codeaustausch und Widerruf, jedoch keinen API-Datenabruf. Zustimmung und Trennung funktionieren bei nativen und Browser-Clients genauso.
Video herunterladen (WebM)
0:00 Ein akzeptierter Tester startet in der Drittanbieter-App und wählt „Link your R+D account“.
0:08 R+D zeigt die App und die angeforderten Rechte. Prüfen Sie diese vor der Zustimmung.
0:14 Wählen Sie „Allow selected permissions“. Der Browser kehrt zur Rückrufadresse der App zurück.
0:19 Der Server prüft den Rückruf und tauscht den Code mit PKCE aus. Die Token bleiben auf dem Server.
0:25 Öffnen Sie zum Prüfen oder Entfernen des Zugriffs R+D-Einstellungen → Verbundene Apps.
0:32 Wählen Sie „Disconnect“. Die App kann diese Verbindung nicht mehr für API-Zugriffe verwenden.
Gemeinsamer Ablauf
- Erzeugen Sie zufälligen State und PKCE-Verifier und speichern Sie sie für den initiierenden Nutzer.
- Öffnen Sie
/oauth/authorizemit Client-ID, genauem Rückruf, Scope, State und S256-Challenge. - Verbrauchen Sie die Transaktion einmalig und prüfen Sie
stateundiss, auch bei Ablehnung. - Senden Sie Code, Rückruf und Verifier formularcodiert an
/oauth/token. Backends authentifizieren sich zusätzlich. - Lesen Sie die erteilten Scopes und senden Sie das Bearer-Token bei erlaubten API-Anfragen.
Verwenden Sie einen fest konfigurierten Issuer pro Umgebung. Metadaten stehen unter
/.well-known/oauth-authorization-server; wählen Sie nie einen Token-Endpunkt aus
einem ungeprüften iss. Token sind undurchsichtig, keine OpenID-Connect-ID-Token.
Fehler behandeln
Bei access_denied nach State-/Issuer-Prüfung unverbunden bleiben. Ungültige,
doppelte oder abgelaufene Rückrufparameter ohne Codeaustausch ablehnen. Einen
abgewiesenen Code nicht wiederverwenden; PKCE, Rückruf, Umgebung und Authentifizierung prüfen.
Bei API-401 gegebenenfalls einmal sicher erneuern oder neu verbinden; bei 403
Scopes und Geräterecht prüfen; bei 429 auf Retry-After warten. Nach unklarem
Refresh-Ergebnis niemals das alte Refresh-Token erneut senden.
Access-Token gelten zehn Minuten. Die Demos fordern kein offline_access an.
Das Limit beträgt 60 API-Anfragen pro Minute, App und Nutzer. Weitere Regeln:
OAuth-Referenz.