Skip to main content

Descripción general

El OAuth de Bluesky se basa en AT Protocol y difiere considerablemente de los proveedores habituales de Socialite como GitHub o Google.
La implementación del OAuth de Bluesky es fundamentalmente distinta a la de otros proveedores de Socialite. Usa DPoP (Demonstrated Proof of Possession) y el endpoint PAR (Pushed Authorization Requests). No se necesita client_secret; en su lugar se utiliza una clave privada.

Diferencias con OAuth convencional

Flujo de autenticación

Instalación y configuración

Crear la clave privada

Genera primero la clave privada. Este paso se puede hacer sin registrar nada en Bluesky.
Copia el valor generado en .env.
En Bluesky no es necesario registrar client_id ni client_secret. Basta con configurar la clave privada para poder usar la autenticación OAuth.

Scopes OAuth por defecto

El paquete se configura con scopes OAuth por defecto que cubren tres casos de uso principales.
  1. Login con Socialite — con atproto, account:email e include:app.bsky.authViewAll se habilita la autenticación del usuario y el acceso al correo.
  2. Publicaciones — con include:app.bsky.authCreatePosts y blob:*/* se permite crear publicaciones y subir imágenes/vídeos.
  3. Notificaciones DM — con rpc:chat.bsky.convo.sendMessage y rpc:chat.bsky.convo.getConvoForMembers se habilita el envío de DMs para notificaciones.
Puedes personalizar los scopes configurando la variable de entorno BLUESKY_OAUTH_SCOPE.
Para más detalles sobre los scopes disponibles, consulta la documentación de AT Protocol Permission Requests.

Desarrollo local

Como por defecto ya están configurados http://localhost y http://127.0.0.1:8000/, no se necesita configuración adicional para desarrollo local.

Entorno de producción

Si existe la ruta con el nombre bluesky.oauth.redirect, no hace falta configurar .env. Si has cambiado el nombre de la ruta por defecto, configúralo aquí.

Configuración de rutas

Se recomienda que el nombre de la ruta de callback sea bluesky.oauth.redirect. El paquete utiliza internamente este nombre.

Gestión del callback en desarrollo local

Durante el desarrollo local, la URL de callback de Bluesky se fija en http://127.0.0.1:8000/. Es cómodo redirigir a nivel de ruta.

Implementación del controlador

Información del usuario (OAuthSession)

Estos son los principales métodos del OAuthSession que puedes obtener desde $user->session. Para ver todas las propiedades, usa toArray().

Configuración de base de datos

Añade a la tabla users las columnas específicas de Bluesky. El DID es el identificador único del usuario en Bluesky.

Reutilización de OAuthSession

Puedes llamar a las APIs usando el OAuthSession guardado en la sesión.
En contextos donde la sesión de Laravel no está disponible, como Jobs o Console, construye el OAuthSession con datos obtenidos de la BD.

Refresco automático de tokens

Como el refresh token solo se puede usar una vez, tras cada refresco es imprescindible volver a guardarlo en la BD. Se utiliza el evento OAuthSessionUpdated.
Al iniciar el refresco también se emite el evento OAuthSessionRefreshing. En ese momento el refresh_token ya no es válido, así que es más seguro eliminarlo de la BD.

Trait WithBluesky

Si añades el trait WithBluesky al modelo User e implementas tokenForBluesky(), puedes obtener un cliente autenticado con $user->bluesky().

Personalizar client-metadata

El paquete define automáticamente las rutas bluesky.oauth.client-metadata y bluesky.oauth.jwks. Normalmente no hace falta cambiar nada, pero puedes personalizarlas con OAuthConfig.

Comportamiento sin autenticación

Si el OAuthSession es null o no hay refresh token, se lanza la excepción Unauthenticated y se redirige a la ruta login.
Última modificación el 13 de julio de 2026