OAuth consent experience design: make delegated access clear

Design OAuth consent as an explicit decision about delegated access: identify the requesting application, show the active account, explain the requested permissions, and offer a clear refusal action. Describe how access can later be managed only where those controls actually exist. The screen should help someone decide—not simply move them toward approval.

OAuth 2.0 enables an application to obtain limited access to an HTTP service, including on behalf of a resource owner through an approval interaction. This guide focuses on that user-facing delegated-access experience. The interface recommendations below are not a prescribed OAuth screen layout. RFC 6749

Separate signing in from granting access

Keep two questions distinct in the interface: “Which account are you using?” and “What may this application do?” OpenID Connect provides an identity layer on top of OAuth 2.0, allowing clients to verify an end user’s identity and obtain basic profile information. Do not reduce a permission decision to a generic “Continue signing in” message. OpenID Connect Core

This distinction also helps organize implementation responsibilities. Ory’s documentation describes Ory Identities, built on Ory Kratos, as an API-first identity and user-management system covering registration, login, recovery, and profile management. It describes Ory Network’s OAuth2 and OpenID Connect service as built on Ory Hydra and connected to Ory Identities by default. Keep those identity-management and protocol-service roles distinct when assigning implementation responsibilities. Ory Kratos introduction · Ory Hydra introduction

For the consent interface, make four answers visible before the user commits:

• Application: Which application is requesting access?
• Account: Which account—and, where relevant, workspace—is involved?
• Permissions: What actions and resources does the request cover?
• Purpose: Which feature needs that access?

Translate permissions into actions on resources

Write permission descriptions from the actual access model. Prefer concrete verbs such as “read,” “create,” or “delete” when the implementation distinguishes those operations. Avoid “manage your calendar” if a more precise explanation is possible.

For a hypothetical calendar integration with separately enforced read and create permissions, a useful presentation might be:

Permission explanation	Feature explanation
Read event titles and times in your selected calendar	Show your agenda in the application
Create events in your selected calendar	Add meetings you schedule in the application

Use descriptions like these only if both the operations and resource boundaries are accurate. Do not say “selected calendar” when the grant covers every calendar. Likewise, do not promise that an application cannot modify or delete data unless the enforced permissions support that statement.

Keep technical scope identifiers available in an expandable details view rather than making them the primary explanation. As an engineering practice, maintain a permission catalog containing each identifier, its user-facing description, its resource boundary, and the feature that needs it. Check that catalog against authorization behavior whenever permissions change.

Make every visible choice affect the resulting access

Only present permissions as optional when the backend and consuming application can honor that distinction. A checkbox should represent a real authorization choice, not a preference that leaves the granted access unchanged.

Where the provider and application support requesting access as features are used, consider asking when the purpose is concrete. For example, explain event-creation access when someone uses a scheduling feature rather than during unrelated onboarding.

For each permission control, test the complete path:

1. Start from a known authorization state.
2. Make a selection on the consent screen.
3. Inspect the resulting authorization.
4. Exercise the corresponding API operation.
5. Confirm that operations outside the resulting authorization remain unavailable.

Test both first-time requests and requests from applications with existing grants. For returning users, distinguish already-granted access from the new decision; do not present an unchecked permission as unavailable if an existing grant still allows it.

If the implementation supports only an all-or-nothing request, explain that constraint plainly. Do not imitate granular controls that the system cannot enforce.

Design refusal and changed requests deliberately

Give refusal a clear label, such as “Don’t allow,” and an understandable consequence. Avoid hiding it behind a low-visibility link or immediately restarting the same request.

For an optional calendar connection, proposed refusal copy could be: “Calendar connection was not enabled. You can keep using the application without calendar synchronization.” Use that wording only when the product actually supports the stated fallback.

Design separate outcomes for a deliberate refusal, an expired request, and a technical failure. Offer an appropriate next step for each instead of treating every unsuccessful journey as an unexplained error.

Also distinguish first-time authorization from requests for additional access. Highlight newly requested permissions while keeping the full proposed access understandable. Explain what refusing the additional request would leave in place. If the system reuses previous decisions, make that behavior a deliberate implementation choice; do not infer it from a returning user’s signed-in state.

Explain disconnection without promising data deletion

Access-management copy needs the same precision as permission copy. RFC 7009 defines a token-revocation mechanism: a revocation request invalidates the specified token and, where applicable, other tokens based on the same authorization grant. It specifies immediate invalidation but acknowledges possible propagation delays between servers. The treatment of related tokens and the underlying grant depends on the authorization server’s revocation policy. RFC 7009

Token revocation is a credential operation, not a basis for promising deletion of previously shared data. Before writing “Disconnect this application,” establish what the product actually does:

• Which credentials or authorization records does the action affect?
• When does enforcement stop accepting existing credentials?
• What happens to data already obtained by the application?

Describe those effects separately. Do not promise immediate termination of every form of access without verifying that behavior.

If the product includes connected-app management, make the destination discoverable from consent and account settings. Explain access duration or access while the user is absent only when the wording matches the deployed configuration.

Evaluate comprehension across the complete journey

WCAG 2.2 provides recommendations for making web content more accessible. Its criteria address programmatically determinable names and roles for interface controls (4.1.2), and status messages that assistive technologies can present without receiving focus (4.1.3). Use it as an accessibility reference, rather than treating a short consent-screen checklist as proof of conformance. WCAG 2.2

Proposed evaluation cases should include keyboard-only operation, visible focus, screen-reader navigation, zoom, long application names, translated permission descriptions, and interrupted requests. Exercise both approval and refusal, including the destination reached afterward.

Evaluate understanding as well as completion. Ask participants to identify the requesting application and active account, explain the requested access in their own words, refuse successfully, and find access-management controls where available.

Track abandonment and repeated prompts as diagnostic signals—not as reasons to pressure people into approval. A useful acceptance criterion is that the user can explain the decision and the system enforces the access the interface described.