A meeting scheduler asks for the password to a corporate calendar. It needs available time slots and permission to create an invitation, but that password may grant far more. When the company stops using the integration, somebody must also find out where else those credentials were reused.
OAuth 2.0 lets an application receive limited access without receiving the user's main password. But “limited” is a design outcome. The protocol does not know whether a scheduler needs private event descriptions, deletion rights or every calendar in the organisation.
Whose authority is being granted?
In a typical user-facing flow, a trusted authorisation service obtains approval and issues an access token to the application. The application presents that credential to an API, which checks it and decides whether the requested operation is permitted. These remain distinct responsibilities even when one provider supplies everything.
Not every flow requires a person at a consent screen. An integration may act for itself or an organisation using previously assigned permissions. Client credentials, for example, supports suitable confidential server clients. The absence of user delegation does not make OAuth irrelevant; RFC 6749 includes both delegated and application access.
For the scheduler, establish whether an employee connects their own calendar or an administrator approves access for an assigned group. An employee leaving and a supplier contract ending then require different actions. Record the authority before implementation so a token does not outlive its business purpose.
Sign-in is a different promise from API access
A “sign in with” button is often described as OAuth login. OAuth primarily addresses access to resources. OpenID Connect adds a standard identity layer, including an ID token conveying information about user authentication.
ID tokens and access tokens serve different audiences and purposes. An ID token is not a universal credential for arbitrary APIs. An access token also need not use JWT, a particular signed-data format. Validation follows the server's contract; accepting a string because it resembles a familiar token proves very little.
“Read calendar” may already be excessive
A scope identifies an area of authority that the API must understand and enforce. Finding a free slot may require availability information but no private meeting titles. Creating invitations is another capability. Asking for everything because it is easier to implement recreates part of the shared-password problem.
The target resource matters as well as the action. A credential intended for one service should not be accepted by another merely because both recognise the issuer. Depending on the token format, validation covers issuer, intended recipient, expiry and permissions. Read access still needs a boundary around which calendars the application may read.
Consent should describe understandable actions, not hide full administrative access behind an internal scope name. Users must not grant authority they do not possess. Organisational approval rules belong in the design, and a click on a consent screen cannot replace server-side enforcement.
Supported does not necessarily mean advisable
For user-facing authorisation, a code flow protected with PKCE is generally an appropriate starting point. PKCE binds the code exchange to the initiating client and helps prevent misuse of an intercepted code. Redirect destinations need registration and strict validation, and responses must be associated with the correct initiating transaction.
RFC 9700 updates OAuth security guidance and prohibits the resource-owner password credentials grant. An old integration example may still run on a permissive server while being unsuitable for a new implementation.
A browser or distributed mobile application cannot reliably keep a shared client secret hidden inside its code. A server-side client with protected storage is a different case. Libraries and configuration must match the client type; homemade checks that merely recognise a token's appearance are not sufficient.
Disconnect the integration while its token still works
A refresh token can obtain new access tokens without repeating the entire user flow. Retirement therefore has two questions: can the integration refresh its access, and can it continue using credentials already issued? Deleting a token from an application's interface does not invalidate another copy.
RFC 7009 defines revocation and recognises propagation delay. An API checking only the signature and expiry of a self-contained token may not learn of revocation immediately without another mechanism. Options include short lifetimes and checking active state through token introspection. Caching an introspection result affects the delay too.
The acceptable revocation window is a product requirement to test, not assume. Revocation also cannot erase data the partner has already copied. Handling those copies requires separate agreements and procedures beyond the token protocol.
Acceptance includes the end of the relationship
For the calendar integration, grant access to availability, verify denial of additional operations, change the assigned group and disconnect while an access token is still valid. The application should show a useful status and stop retrying forbidden requests indefinitely.
Support needs the client identity, granted permissions and operation outcome, not raw tokens in logs. Repeat the checks when an integration changes owner or authority. Connecting a partner begins its lifecycle; the ability to end that access properly belongs in the same release rather than a later response to a leak.