11 August 2026: scopes and consent platform update

Update date: 11 August 2026

Swaymoon Account and the Developer portal have shipped this round of scopes-and-consent changes. This page covers what changed, what is deprecated, what stays compatible, and what you should do.

Compatibility

• Existing production clients do not need code changes or a new release because of this update.
• New integrations and newly developed clients should follow the latest developer docs.

Summary

• You can add or remove identifier scopes in the Developer portal (you do not have to recreate the client to change scopes).
• When you make a scope required, you must provide a user-visible reason and a privacy policy URL.
• Users must explicitly confirm on the authorization page every sign-in. Prior consent for the same scopes is no longer silently reused.
• When scopes are added or removed, users clearly see new / no longer requested / still granted, and they choose new optional scopes.
• Older apps that cannot change sign-in code can still have users reconfirm after you change scopes in the portal (see “How older apps stay compatible”).

Detailed behavior: Scopes and consent and Registration and configuration one level up in this directory.

What changed

Developer portal

• The Edit identifier wizard includes a Capabilities step to adjust required / optional scope.
• email and profile fields (such as name, preferred_username, picture) can each be: not requested / optional / required.
• Required scopes need a reason shown to the user (next to that scope on the authorization page).
• If any required scope other than openid is present, a privacy policy URL is required.
• API: create / update client may send requiredScopes, optionalScopes, scopeReasons, privacyPolicyUri. Updates persist scope changes.

User authorization page

• Every sign-in reaches the authorize / confirm page (consent is not silently reused).
• Scopes unchanged for that user: Confirm sign-in and a summary of already granted items.
• Scopes added or removed: Permissions have changed, with sections for new required / new optional (with reasons), no longer requested, and still granted. After confirm, removed scopes are dropped.
• First authorization: Required / Optional sections; reasons next to required items.

Docs

• Scopes and consent, Registration and configuration, Integration overview, the Python example, and related pages now match this behavior.
• New-client integration notes follow those latest docs.

How older apps stay compatible (plain language)

On OAuth sign-in, the app opens Swaymoon Account and puts the scopes for this request in the URL, for example:

scope=openid email

That string lives in your app code. Some shipped apps cannot change it soon (long release cycles, unmaintained, and similar).

Where it would break

If you later make username required in the Developer portal, but the old app still sends only openid email:

• Under the raw protocol, the authorization page and tokens would only handle scopes written in the request;
• The user would not see username, and the token would not include it;
• The portal would have changed, but the old app would not get the new scope.

What the server does

When Swaymoon Account handles the sign-in request, it fills in scopes registered in the portal. Old apps do not need code changes:

1. All required scopes are merged in
   Scopes marked required in the portal (for example a newly required username) appear in this authorization even if the app URL omitted them. The user must confirm.

2. Signed-in users also see “new optional” items
   If you add an optional scope in the portal (for example avatar) and the user has never granted it, the next confirmation page lists it to check or uncheck.
   Optional scopes the user already granted are not shown again as “new”.

3. If the user is not signed in yet
   Required scopes are merged first. After sign-in returns to the authorization flow, new optional scopes are added.

Examples

Bottom line: old apps can skip code changes for now. After you change scopes in the portal, the next sign-in still completes confirmation. New apps should still list needed scope in the request and keep it aligned with portal registration.

What is deprecated

The following are no longer product guarantees. Do not rely on them in new work:

Not deprecated: expansion compatibility for profile / historical name, required PKCE, pairwise sub, and other existing protocol behavior.

What stays compatible

• Existing production clients: no need to change the sign-in request, prompt, or ship a new release. Portal scope edits and the required confirmation page are handled on the Swaymoon Account side (see “How older apps stay compatible”).
• Old scope strings: you may still send profile or historical name; the server expands them into field scopes (see Scopes and consent).
• Identifier identity: client_id / secrets and client type are not invalidated by this update. Type still cannot be switched.
• Tokens and UserInfo: ungranted fields remain default placeholders. Interpret claims from scope in the token response.

What you should do

1. Maintained older apps: you can skip code changes for now. If you add or remove scopes or add required items in the portal, complete reasons and a privacy policy, and expect the next sign-in to show confirmation or a change comparison.
2. New integrations / new development: configure scope per the latest Registration and configuration and Scopes and consent. Design sign-in UX around “the confirmation page appears every time”. Do not assume silent authorization.
3. When you must require a scope: write a user-visible purpose, and provide a privacy policy URL the user can open.

Related links

• Developer portal: https://develop.swaymoon.com/
• One level up in this directory: Scopes and consent, Registration and configuration, Integration overview