In OAuth terminology, scope is a way to limit what parts of your account are accessible by third-party applications.
For example, you can choose to allow one application to read your basic profile info, while another application may be authorized to post on your behalf.
Micropub clients use scopes to indicate what permissions they are requesting from Micropub servers, which will result in the user seeing the listed scopes in the authorization prompt. Clients and servers must agree on the names and expected behavior of a list of scopes in order to provide a consistent user experience among apps.
Listed below are the currently supported Micropub scopes across most clients and servers.
create- allows the client to create posts on behalf of the user
draft- (proposed) allows the client to create draft posts only on behalf of the user (requested in lieu of create scope)
update- allows the client to edit existing posts
delete- allows the client to delete posts
media- allows the client to upload files to the media endpoint
These are distinct permissions, so e.g. granting a client only "create" scope means it will not be able to update or delete existing posts.
Most servers allow clients with the
create scope to also allow uploading to the media endpoint. The
media scope can be used to allow clients to only upload to the media endpoint without being able to also create posts.
Use the sections below to document additional experimental scopes that software has implemented, and once there are two or more clients and servers that support the additional scopes, they can be added to the registry above.
Scopes supported by Micropub clients
- Quill requests the "create" and/or "update" scope when authorizing it to create posts on your domain.
- OwnYourGram requests the "create" scope when authorizing it to create photo posts on your domain.
- Micropublish.net requests the scopes "post" or "create update delete undelete", for the user to choose
- Indigenous requests the "create", "update" and "delete" scopes when logging in to the app.
- indiebookclub requests the "create" scope.
- Indiepaper requests the "create", "update", and "save" scopes when logging in.
- Micro.blog requests the "create" scope.
- Sunlit requests the "create" scope.
Scopes supported by Micropub servers
- Known supports _____
- The Wordpress Micropub plugin uses WordPress capabilities and those capabilities are edited based on scope by the WordPress IndieAuth plugin.
- The create, draft, update, delete, and media scopes are supported. The profile scope is listed but currently is not implemented as a capability.
- Aaron Parecki requires the "create" scope in order for a client to create new posts, "update" for updates, and "delete" for deletes. "media" for file uploads. if the client is issued a token that contains the "draft" scope, that client can only create draft posts.
- Pelle Wessman, using his micropub-to-github endpoint, requires the "create" or "post" scope for a client to give access, treating "create" as the preferred one
- Sebastiaan Andeweg uses scopes "create", "update", "delete", "media" (for photo upload) and "media-plus" (for uploads without limitations on file extension)
- Jamie Tanna uses "create", "update", "delete", "media" (for photo upload), and "undelete" (to undelete posts, or to view deleted posts via `q=source`)
- Jamie is also planning on adding the "notify" scope to allow for sending push notifications
Microsub clients use scopes to indicate what actions they are requesting to be able to take on the user's account.
read- this is the minimum scope clients should request. this allows clients to have read access to channels.
follow- allows the client to manage the following list
mute- allows the client to mute and unmute users
block- allows the client to block and unblock users
channels- allows the client to manage channels
There is a proposal implemented by some for returning profile data in IndieAuth responses in order to allow a client to display username and profile photo over just URL. https://github.com/indieweb/indieauth/issues/31
Some sites may choose to return this to all. For sites that choose not to, there is a proposal that this can use the profile scope, and that additional properties can mirror openid connect, where additional properties require added scopes.
profile- provide basic profile data. Sites can optionally require this for all profile data, or provide some profile data in all returns.
undelete- allows the client to undelete a deleted post, if possible
notify- allows the client to send push notifications to the user
Scopes used by Silos
Github has defined many scopes for granting very granular permissions to applications. By default, applications can only read public profile info unless granted explicit scopes. Write access to any parts of a user account must be explicitly authorized with one or more scopes such as "user", "repo", or "gist". Deleting repos requires a specialized scope as well.
See the full list of Github OAuth scopes.
Scopes that conform to the OpenID Connect standard have full names that are short: profile, email and openid—they are not in the form of a URI. On the other hand, Google-specific scopes are in the form of a URI, such as https://www.googleapis.com/auth/plus.login
See also: Authorization scopes