Bluesky: AT Protocol OAuth permissions and permission sets ship, replacing app-password-level access

AT Protocol OAuth permissions and permission sets ship, replacing app-password-level access

Announced24 Mar 2026

EffectiveNot stated

PlatformBluesky

What changed

The AT Protocol spring 2026 roadmap of March 24, 2026 reported that OAuth "permissions and permission sets shipped" in the previous six months. Apps can request individual permissions of five types (repo, rpc, blob, identity, account) or bundles called permission sets, referenced with include: in the scope string. The OAuth spec keeps transition:generic, transition:chat.bsky and transition:email as transitional scopes matching the old app password levels and says the goal is to deprecate and eventually remove them. No removal date is given.

What it means

Scheduling tools that use OAuth can ask only for what they need, such as writing posts and uploading media, instead of the broad transition:generic scope that equals app password access.

Who is affected

Developers of Bluesky scheduling, posting and analytics tools that use OAuth, and users who authorise those tools.

What to do

Replace transition:generic with granular permissions (for example repo permissions for the record types you write and blob:*/* for images and video) or published permission sets, and keep the scope in oauth-client-metadata.json identical to the one in your authorization request.

What this means for you

When you connect a scheduling app to Bluesky, it asks for permission. Until now the usual request was "do almost anything", the same as an app password. Apps can now ask for just what they need, like "write posts and upload pictures." You see a clearer list of what you are allowing. Prefer apps that ask for less.

The details

Status: the March 24, 2026 roadmap lists "OAuth Completeness: permissions and permission sets shipped" among the work since October 2025. The post gives no exact ship date.
Permission types: repo (write records, for example repo:com.example.post?action=create), rpc (authenticated calls to a service, with aud), blob (media uploads, for example blob:*/* or blob:image/*), identity and account (for example account:email). blob and account cannot be put in permission sets.
Permission sets: Lexicon schemas that bundle permissions with a human-readable title, referenced as include:<nsid>. Apps using only existing Lexicons such as app.bsky.* can reference published permission sets or request granular permissions.
Wildcards: full wildcards like blob:*/* are allowed; partial ones like repo:app.bsky.* are not.
Scope matching: OAuth uses Pushed Authorization Requests, and the scope in oauth-client-metadata.json "needs to match" the authorization request.
Transitional scopes: transition:generic equals the old app password level (any record, blobs, preferences, most proxying; no account management, no DMs); transition:chat.bsky adds DMs and needs transition:generic; transition:email exposes the email in getSession. "The goal is to deprecate and eventually remove these transitional scopes."
Earlier steps: OAuth specification and OAuth improvements.

What to do next

Business owners: When you connect an app, read the permission screen and be wary of apps asking for more than posting.
Marketers and agencies: Ask your Bluesky tool whether it supports OAuth with granular permissions instead of app passwords.
Developers: Request repo permissions for the records you write plus blob:*/* for media, keep client metadata and request scopes in sync, and plan to drop transition:generic.

Follow new entries with the RSS feed. Each platform also has its own feed, for example X or Meta.