- Backend redeems a single-use code
- AnyOAuth issues a short-lived profile token
- Backend fetches the signed-in identity
A variable called accessToken doesn’t tell you what it can access. The issuer, resource server, and permitted operations do.
That’s why a sign-in callback needs more careful names than “get token, save token, done.” An authorization code, a provider access token, an AnyOAuth profile token, and your application session aren’t interchangeable. Each crosses a different boundary.
The resource defines what the token does
An AnyOAuth profile token authorizes a request to the AnyOAuth profile API for the signed-in identity. It is opaque: your app doesn’t decode it as a JWT to discover claims.
Use the backend SDK’s profile method or the documented profile endpoint. Don’t send it to a provider’s repository, calendar, or mail endpoint. Those resources don’t recognize it as their credential, and AnyOAuth doesn’t expose the underlying provider tokens to your app.
| Credential | What uses it | What it is for |
|---|---|---|
| Project client secret | Your backend and AnyOAuth | Authenticate code redemption |
| Handoff code | Your backend and AnyOAuth | Single-use exchange tied to the transaction |
| Profile token | Your backend and AnyOAuth profile API | Retrieve the signed-in profile |
| Session cookie | Browser and your application | Maintain your application’s login |
Naming these separately makes a code review much easier. It also gives an AI assistant less room to invent a refresh flow or a JWT parser that the contract doesn’t contain.
Fifteen minutes is not your session duration
The profile token expires after 15 minutes. There’s no refresh token. That lifetime limits the profile credential’s use; it doesn’t decide how long the user is signed into your application.
Typically, the backend needs the token only long enough to fetch the profile and resolve an application user. After your app issues its own session, it can revoke the profile token. Your app’s session can have the lifetime and revocation policy your product requires.
If the profile token expires before retrieval, don’t keep retrying an expired credential. Start a new sign-in transaction when appropriate. If the application cookie expires later, handle that according to your app’s session design. Those are different failures.
- During the handoff: use the profile token to retrieve identity.
- After identity resolution: issue your application's session and revoke the now-unneeded profile token.
- On later requests: validate your application's session, not the old profile token.
A narrow token is still a bearer credential
Profile-only does not mean harmless. Whoever holds a valid bearer token can exercise the access it grants. Keep it out of analytics events, URLs, screenshots, and callback logs.
AnyOAuth stores profile tokens as hashes and checks expiration when they’re used. Hashing helps protect stored bearer credentials; it does not make a token safe to expose while it is live, nor does it protect against every kind of runtime compromise.
Treat the value as temporary backend data. Avoid saving it in a long-lived application user record “just in case.” If your application never needs to retrieve the profile again after session creation, storing it adds a credential without adding a feature.
Where AnyOAuth fits
AnyOAuth, which we build, is a sign-in handoff rather than a provider-token vault. The provider integration establishes identity, the service issues a profile-only token, and your application takes over session management.
That fits apps that need social login without provider API access. If you’re building a repository browser, an inbox client, or a calendar integration, you’ll need the relevant provider authorization flow and permission model. A sign-in profile is not a substitute for delegated access to those resources.
The distinction is central to what OAuth actually delegates. For the application-facing flow, read redirect, exchange, profile. For the step after it, read your app owns the session.
Sources and implementation references
- AnyOAuth quickstart and security model, reviewed 2026-10-06.
- RFC 6750: OAuth 2.0 Bearer Token Usage, retrieved 2026-10-06.
- RFC 9700: Best Current Practice for OAuth 2.0 Security, retrieved 2026-10-06.