Authentication overview

Bluesky's authentication system is built on the AT Protocol, an open-source federated protocol for large-scale distributed applications. This design prioritizes user control over data and identity, enabling users to move their accounts between different service providers without losing their data or social graph. Key to this model are Decentralized Identifiers (DIDs), which serve as persistent, globally unique identifiers for users on the network.

When an application interacts with the Bluesky network on behalf of a user, it authenticates by exchanging an App Password for a session token. This session token grants temporary, scoped access to the user's account, allowing the application to perform actions such as posting, reading feeds, or managing profile information. The use of App Passwords enhances security by providing revocable, application-specific credentials distinct from the user's primary account password. The AT Protocol aims to provide a robust framework for decentralized social applications, emphasizing cryptographic verification and user agency.

Supported authentication methods

Bluesky's AT Protocol primarily uses a token-based authentication flow secured by Decentralized Identifiers (DIDs) and application-specific passwords. This approach ensures that direct user credentials are not exposed to third-party applications and provides a mechanism for revoking access without impacting other client applications.

The following table outlines the primary authentication mechanism and its characteristics:

Method When to Use Security Level
App Password + Session Token Programmatic access for custom clients, bots, or integrations; any scenario requiring API interaction on behalf of a user. High. App Passwords are unique, revocable, and scoped, preventing direct exposure of primary account credentials. Session tokens are short-lived and refreshed.

Unlike traditional OAuth2 flows which involve explicit authorization screens for scopes, Bluesky's model relies on the user generating an App Password, which implicitly grants the application access to perform actions on their behalf. This simplifies the developer experience for creating custom clients while maintaining user control through revocable credentials. The underlying protocol handles the secure exchange of these credentials for session tokens, which are then used to authorize subsequent API requests.

For a deeper understanding of DID-based authentication, the W3C Decentralized Identifiers (DIDs) specification provides foundational information on how these unique identifiers function across decentralized networks.

Getting your credentials

To authenticate with the Bluesky API, you need to obtain an App Password from your Bluesky account. This password is distinct from your main account password and is designed for use with third-party applications or custom integrations.

Follow these steps to generate an App Password:

  1. Log in to Bluesky: Access the official Bluesky web application or a trusted client.
  2. Navigate to Settings: Go to your account settings or profile management section. The exact path may vary slightly between clients, but typically look for an option like 'Settings' or 'App Passwords'.
  3. Find App Passwords: Within settings, locate the 'App Passwords' or 'Authorized Apps' section.
  4. Generate New App Password: Click the option to 'Generate a new App Password' or 'Create App Password'. You will typically be prompted to provide a label for the password, which helps you identify its purpose later (e.g., "My Custom Client" or "Data Backup Script").
  5. Copy the App Password: After creation, the App Password will be displayed. It is crucial to copy this password immediately as it is often shown only once and cannot be retrieved later. Treat it like a sensitive credential.

Once you have your App Password, you will use it along with your Bluesky username (or handle) to initiate an authentication request to the AT Protocol's PDS (Personal Data Server). The PDS will then issue a session token, which you will include in the Authorization header of subsequent API requests.

For detailed instructions, refer to the Bluesky developer guide on authentication.

Authenticated request example

This example demonstrates how to authenticate with the Bluesky AT Protocol using an App Password and then make a simple authenticated request to retrieve the user's profile. We'll use the official TypeScript SDK for clarity.

import { BskyAgent } from '@atproto/api';

const agent = new BskyAgent({
  service: 'https://bsky.social',
});

async function authenticateAndFetchProfile(identifier: string, appPassword: string) {
  try {
    // 1. Authenticate using identifier (handle or DID) and App Password
    const response = await agent.login({
      identifier: identifier, // Your Bluesky handle (e.g., 'yourhandle.bsky.social') or DID
      password: appPassword, // The generated App Password
    });

    console.log('Authentication successful:', response.data.did);

    // 2. Make an authenticated request - e.g., fetch your own profile
    const profile = await agent.getProfile({ actor: identifier });

    console.log('Fetched profile:', profile.data.displayName, profile.data.description);

    // The session token is automatically managed by BskyAgent after login
    // You can inspect it if needed, but the agent handles its lifecycle.
    // console.log('Current session token:', agent.session?.accessJwt);

  } catch (error) {
    console.error('Authentication or request failed:', error);
  }
}

// Replace with your actual handle and App Password
const myHandle = 'yourhandle.bsky.social'; // Or your DID
const myAppPassword = 'your-secret-app-password';

authenticateAndFetchProfile(myHandle, myAppPassword);

In this example:

  • BskyAgent is initialized with the service endpoint (typically https://bsky.social).
  • The agent.login() method sends your handle/DID and App Password to the service. If successful, it receives a session token, which the agent internally stores and uses for subsequent authenticated requests.
  • The agent.getProfile() method then makes an authenticated API call without needing to manually attach the session token, as the BskyAgent handles this automatically after a successful login.

For more detailed API interactions and other methods, consult the AT Protocol API reference.

Security best practices

Adhering to security best practices when authenticating with Bluesky APIs is crucial for protecting user data and maintaining the integrity of your applications.

  1. Use App Passwords: Always use App Passwords for programmatic access instead of your primary account password. App Passwords are revocable and provide a layer of isolation, limiting the impact if a credential is compromised.
  2. Generate Unique App Passwords: Create a unique App Password for each application or integration. This allows you to revoke access for a specific application without affecting others.
  3. Store App Passwords Securely: Never hardcode App Passwords directly into your application code. Use environment variables, secure configuration files, or dedicated secret management services (e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) to store credentials.
  4. Protect Session Tokens: Once you receive a session token, treat it as sensitive data. Store it securely (e.g., in HTTP-only cookies for web applications, or secure storage for mobile apps) and ensure it's transmitted only over HTTPS. Avoid logging session tokens.
  5. Implement Token Refresh: Bluesky session tokens have a limited lifespan. Implement logic to refresh tokens before they expire to maintain continuous access without requiring re-authentication. The official SDKs typically handle this automatically.
  6. Revoke Unused Credentials: Regularly review and revoke App Passwords that are no longer in use or associated with deprecated applications.
  7. Input Validation and Sanitization: Sanitize and validate all user inputs to prevent injection attacks (e.g., XSS) that could compromise authentication flows or expose credentials.
  8. Use HTTPS/TLS: Ensure all communication with the Bluesky PDS (Personal Data Server) or relay is encrypted using HTTPS/TLS to prevent eavesdropping and man-in-the-middle attacks during credential exchange and API calls.
  9. Error Handling: Implement robust error handling for authentication failures. Avoid providing overly descriptive error messages that could leak information to potential attackers.
  10. Keep Dependencies Updated: Regularly update your SDKs and other dependencies to benefit from the latest security patches and improvements. The @atproto/api npm package for TypeScript/JavaScript developers is regularly maintained.