Skip to main content

Panoramica

L’OAuth di Bluesky è basato su AT Protocol e differisce sostanzialmente dai provider Socialite tipici come GitHub o Google.
L’implementazione dell’OAuth di Bluesky è fondamentalmente diversa da quella degli altri provider Socialite. Usa DPoP (Demonstrated Proof of Possession) e l’endpoint PAR (Pushed Authorization Requests). Non è necessario client_secret: si usa invece una chiave privata.

Differenze rispetto al normale OAuth

Flusso di autenticazione

Installazione e configurazione

Creazione della chiave privata

Prima genera la chiave privata. Puoi farlo senza registrarti su Bluesky.
Copia il valore emesso in .env.
Con Bluesky non è necessario registrare client_id o client_secret. Puoi usare l’autenticazione OAuth con la sola configurazione della chiave privata.

Scope OAuth predefiniti

Il pacchetto è configurato con scope OAuth predefiniti che coprono tre casi d’uso principali.
  1. Login con Socialite — con atproto, account:email e include:app.bsky.authViewAll abilita l’autenticazione utente e l’accesso all’email
  2. Post — con include:app.bsky.authCreatePosts e blob:*/* consente la creazione di post e l’upload di immagini/video
  3. Notifiche DM — con rpc:chat.bsky.convo.sendMessage e rpc:chat.bsky.convo.getConvoForMembers abilita l’invio di messaggi diretti per le notifiche
Puoi personalizzare gli scope impostando la variabile d’ambiente BLUESKY_OAUTH_SCOPE.
Per i dettagli degli scope disponibili consulta la documentazione AT Protocol Permission Requests.

Sviluppo locale

Per impostazione predefinita sono configurati http://localhost e http://127.0.0.1:8000/, quindi in sviluppo locale non serve nessuna configurazione aggiuntiva.

Ambiente di produzione

Se esiste una rotta chiamata bluesky.oauth.redirect, non serve configurare .env. Configuralo solo se hai cambiato il nome della rotta predefinito.

Configurazione delle rotte

Come nome della rotta di callback è consigliato bluesky.oauth.redirect. Il pacchetto usa questo nome internamente.

Gestione del callback in sviluppo locale

Durante lo sviluppo locale, l’URL di callback da Bluesky è fisso su http://127.0.0.1:8000/. È comodo smistarlo a livello di rotta.

Implementazione del controller

Informazioni utente (OAuthSession)

I metodi principali dell’OAuthSession ottenibile da $user->session sono i seguenti. Per vedere tutte le proprietà usa toArray().

Configurazione del database

Aggiungi alla tabella users le colonne specifiche di Bluesky. Il DID è l’identificatore univoco dell’utente Bluesky.

Riutilizzo di OAuthSession

Puoi invocare le API usando l’OAuthSession salvato in sessione.
Nei job o nella Console, dove la sessione Laravel non è disponibile, ricostruisci l’OAuthSession dai dati del DB.

Aggiornamento automatico del token

Il refresh token può essere usato una sola volta, quindi dopo l’aggiornamento devi risalvarlo obbligatoriamente in DB. Usa l’evento OAuthSessionUpdated.
All’inizio del refresh viene emesso anche l’evento OAuthSessionRefreshing. A quel punto il refresh_token diventa invalido, quindi conviene rimuoverlo dal DB per sicurezza.

Trait WithBluesky

Aggiungendo il trait WithBluesky al model User e implementando tokenForBluesky(), puoi ottenere un client autenticato tramite $user->bluesky().

Personalizzazione del client-metadata

Il pacchetto definisce automaticamente le rotte bluesky.oauth.client-metadata e bluesky.oauth.jwks. Di norma non serve modificare nulla, ma puoi personalizzarle tramite OAuthConfig.

Comportamento in assenza di autenticazione

Se OAuthSession è null o manca il refresh token, viene lanciata un’eccezione Unauthenticated e vieni reindirizzato alla rotta login.
Ultima modifica il 13 luglio 2026