Lorsqu’une application se connecte au PDS d’un utilisateur via OAuth, elle demande un ensemble de permissions appelées scopes. Le PDS les présente à l’utilisateur au moment de l’authentification, et celui-ci choisit de les accorder ou non. Chaque scope décrit précisément ce que l’application pourra faire avec le compte.
Scope obligatoire
| Scope | Signification | Exemple |
|---|---|---|
atproto | Confirme l’usage du profil atproto d’OAuth. Requis dans toute session ; sans lui, aucun accès aux ressources du PDS. Seul, il ne permet que l’authentification du compte (DID renvoyé dans sub) | atproto |
Scopes transitoires
Ces scopes reproduisent les permissions larges des « App Passwords » en attendant que les applications adoptent les scopes granulaires.
| Scope | Signification | Exemple |
|---|---|---|
transition:generic | Permissions larges équivalentes à une « App Password » : écriture de tout type d’enregistrement, upload de blobs, lecture/écriture des préférences, appels et proxying de la plupart des endpoints Lexicon, génération de service auth tokens. Exclut la gestion de compte (handle, email, suppression, migration) et les DMs | transition:generic |
transition:chat.bsky | Équivalent du toggle « DM Access » : endpoints et proxying chat.bsky, plus les service auth tokens associés. Ne fonctionne pas sans transition:generic | transition:chat.bsky |
transition:email | Accès à l’adresse email : elle est incluse, avec son statut de vérification, dans la réponse de com.atproto.server.getSession | transition:email |
Scopes granulaires
Chaque scope granulaire cible une ressource précise et accepte des paramètres
qui en restreignent la portée. Le scope include permet de référencer un
permission set, c’est-à-dire un groupe de scopes granulaires publié comme
schéma Lexicon.
| Scope | Signification | Paramètres | Exemple |
|---|---|---|---|
repo | Écriture des enregistrements du dépôt public, limitable par type d’enregistrement et par action | collection (positionnel, requis, * autorisé), action (create/update/delete, toutes par défaut) | repo:app.bsky.feed.post?action=create |
rpc | Requêtes API authentifiées vers des services distants (service auth tokens et proxying via le PDS). Au moins un des deux paramètres doit être restreint | lxm (positionnel, requis, * autorisé), aud (DID + fragment de service), inheritAud (permission sets uniquement) | rpc:app.bsky.feed.getFeed?aud=did:web:api.bsky.app%23bsky_appview |
blob | Upload de fichiers média vers le PDS. Interdit dans un permission set | accept (positionnel, requis : types MIME ou globs) | blob:image/* |
account | Contrôle des détails d’hébergement du compte. Attributs : email (lecture ou modification) et repo (manage = import d’un CAR complet). Interdit dans un permission set | attr (positionnel, requis, pas de wildcard), action (read par défaut, ou manage) | account:email, account:repo?action=manage |
identity | Contrôle du document DID et du handle. Attributs : handle ou * (contrôle total). Interdit dans un permission set | attr (positionnel, requis) | identity:handle, identity:* |
include | Référence un permission set : un groupe de permissions publié comme schéma Lexicon, résolu dynamiquement par le serveur d’autorisation et présenté à l’utilisateur avec titre et description | NSID du set (positionnel), aud (transmis aux permissions ayant inheritAud) | include:app.bsky.authBasic?aud=did:web:api.bsky.app%23bsky_appview |
Sources : https://atproto.com/specs/oauth (section « Authorization Scopes ») et https://atproto.com/specs/permission.