Bluesky OAuthlient, with Vanilla JavaScript

This post details integrating Bluesky Authentication (OAuth DPoP) into a serverless client application using only Vanilla JavaScript. It's a conceptual illustration, not a fully functional example due to token expiration.

Introduction

We'll explore how to implement Bluesky authentication in a JavaScript application without relying on external frameworks.

Disclaimer

This is a tutorial demonstrating the process. Due to the ephemeral nature of authentication tokens, it won't function as a standalone, perpetually working example. Please report any errors.

OAuth Authentication

For a serverless application requiring user authentication, we can leverage a third-party authority like Bluesky. This uses the OAuth 2.0 protocol. More details on Bluesky's OAuth implementation can be found in the OAuth - AT Protocol documentation.

Client Metadata

To utilize Bluesky authentication, our application needs to be recognized by Bluesky's authentication servers. This is achieved via a client metadata file (e.g., client-metadata.json) containing application information. This allows for automated client registration, eliminating the need for manual server registration. The metadata file must be accessible via HTTPS.

An example metadata file (accessible at https://www.php.cn/link/db817217c5d9b196aa39cfeb0ce889e4):

{
  "client_id":"https://www.php.cn/link/db817217c5d9b196aa39cfeb0ce889e4",
  "application_type":"web",
  "grant_types":[
    "authorization_code",
    "refresh_token"
  ],
  "scope":"atproto transition:generic transition:chat.bsky",
  "response_types":[
    "code id_token",
    "code"
  ],
  "redirect_uris":[
    "https://madrilenyer.neocities.org/bsky/oauth/callback/"
  ],
  "dpop_bound_access_tokens":true,
  "token_endpoint_auth_method":"none",
  "client_name":"Madrilenyer Example Browser App",
  "client_uri":"https://madrilenyer.neocities.org/bsky/"
}

This file describes our application to the Bluesky authentication servers.

Core Authentication Requirements

To authenticate a user, we minimally require their Bluesky handle. The handle is the portion of the Bluesky profile URL after https://bsky.app/profile/.

Retrieving User Data

1. Retrieve DID: Given a user's handle, we can fetch their Decentralized Identifier (DID) using an API call (e.g., https://bsky.social/xrpc/com.atproto.identity.resolveHandle?handle=<handle>).

2. Retrieve DID Document: Using the DID, we retrieve the DID Document from the PLC API (https://plc.directory/<did>). This document contains the user's PDS (Personal Data Server) URL.

3. Retrieve PDS Metadata: The PDS URL (serviceEndpoint in the DID Document) is used to fetch the PDS metadata from /.well-known/oauth-protected-resource. This metadata provides the authorization server URL.

4. Authorization Server Discovery: The authorization server URL is used to retrieve its metadata from /.well-known/oauth-authorization-server. This metadata contains crucial endpoints like the authorization endpoint, token endpoint, and pushed authorization request (PAR) endpoint.

The subsequent steps involve using the discovered endpoints and PKCE (Proof Key for Code Exchange) to obtain the user's access token, a process involving PAR requests, DPoP (Demonstrate Proof of Possession) for enhanced security, and handling redirects. The detailed Javascript code for these steps, while omitted for brevity, would involve making several API calls and handling the responses. The official Bluesky TypeScript client is a more robust and recommended alternative for production applications.

The above is the detailed content of Bluesky OAuthlient, with Vanilla JavaScript. For more information, please follow other related articles on the PHP Chinese website!