Skip to main content

Überblick

Blueskys OAuth basiert auf dem AT Protocol und unterscheidet sich deutlich von gewöhnlichen Socialite-Providern wie GitHub oder Google.
Blueskys OAuth ist in seiner Implementierung grundsätzlich anders als andere Socialite-Provider. Es verwendet DPoP (Demonstrated Proof of Possession) und den PAR-Endpunkt (Pushed Authorization Requests). Ein client_secret wird nicht benötigt, stattdessen kommt ein privater Schlüssel zum Einsatz.

Unterschied zum normalen OAuth

Authentifizierungsfluss

Installation und Konfiguration

Privaten Schlüssel erstellen

Erzeugen Sie zunächst einen privaten Schlüssel. Das ist ohne Registrierung bei Bluesky möglich.
Kopieren Sie den ausgegebenen Wert in .env.
Bei Bluesky ist keine Registrierung eines client_id oder client_secret erforderlich. Allein mit dem privaten Schlüssel können Sie die OAuth-Authentifizierung nutzen.

Standard-OAuth-Scopes

Das Paket ist mit Standard-OAuth-Scopes vorkonfiguriert, die drei Hauptanwendungsfälle abdecken.
  1. Socialite-Login – Aktiviert Nutzer-Authentifizierung und E-Mail-Zugriff über atproto, account:email, include:app.bsky.authViewAll.
  2. Posten – Erlaubt das Erstellen von Posts und das Hochladen von Bildern/Videos über include:app.bsky.authCreatePosts und blob:*/*.
  3. DM-Benachrichtigungen – Aktiviert das Versenden von DMs für Benachrichtigungen über rpc:chat.bsky.convo.sendMessage und rpc:chat.bsky.convo.getConvoForMembers.
Sie können die Scopes über die Umgebungsvariable BLUESKY_OAUTH_SCOPE anpassen.
Details zu den verfügbaren Scopes finden Sie in der AT-Protocol-Dokumentation zu Permission Requests.

Lokale Entwicklung

Standardmäßig sind http://localhost und http://127.0.0.1:8000/ konfiguriert, sodass für die lokale Entwicklung keine zusätzliche Konfiguration nötig ist.

Produktivumgebung

Wenn der Routenname bluesky.oauth.redirect existiert, ist kein Eintrag in .env nötig. Wenn Sie den Standard-Routennamen ändern, konfigurieren Sie ihn.

Routen-Setup

Für die Callback-Route wird der Routenname bluesky.oauth.redirect empfohlen. Das Paket verwendet diesen Namen intern.

Callback-Handling in der lokalen Entwicklung

Während der lokalen Entwicklung ist die Callback-URL von Bluesky fest auf http://127.0.0.1:8000/ gesetzt. Es ist praktisch, das Routing dafür auf Route-Ebene vorzunehmen.

Controller-Implementierung

Nutzerinformationen (OAuthSession)

Die wichtigsten Methoden der über $user->session verfügbaren OAuthSession: Alle Eigenschaften prüfen Sie mit toArray().

Datenbank-Konfiguration

Fügen Sie der Tabelle users Bluesky-spezifische Spalten hinzu. Die DID ist der eindeutige Identifier eines Bluesky-Nutzers.

Wiederverwendung der OAuthSession

Mit der in der Session gespeicherten OAuthSession können Sie APIs aufrufen.
Wenn Sie in Jobs oder in der Konsole keine Laravel-Session verwenden können, bauen Sie die OAuthSession aus den DB-Werten zusammen.

Automatisches Token-Refreshing

Da das Refresh-Token nur einmal verwendet werden kann, muss es nach dem Aktualisieren unbedingt erneut in der DB gespeichert werden. Verwenden Sie hierfür das Event OAuthSessionUpdated.
Beim Beginn eines Refreshs wird zudem das Event OAuthSessionRefreshing ausgelöst. Da das refresh_token ab diesem Zeitpunkt ungültig ist, sollten Sie es sicherheitshalber aus der DB entfernen.

Trait WithBluesky

Wenn Sie dem User-Modell den Trait WithBluesky hinzufügen und tokenForBluesky() implementieren, können Sie über $user->bluesky() einen authentifizierten Client abrufen.

Client-Metadata anpassen

Das Paket definiert automatisch die Routen bluesky.oauth.client-metadata und bluesky.oauth.jwks. Änderungen sind meist nicht nötig, mit OAuthConfig können Sie sie aber anpassen.

Verhalten ohne Authentifizierung

Wenn OAuthSession null ist oder kein Refresh-Token vorliegt, wird eine Unauthenticated-Exception ausgelöst und ein Redirect zur login-Route ausgeführt.
Zuletzt geändert am 13. Juli 2026