# A profile token, not a pass to someone's account

An AnyOAuth token retrieves one signed-in user's profile. It doesn't read their inbox, fetch their repositories, or keep them logged into your app. That smaller boundary is intentional.

By Gabe. Published 2026-10-06.
Author: https://anyoauth.com/blog/authors/gabe/
Source: https://anyoauth.com/blog/a-profile-token-not-a-provider-token/

1. Backend redeems a single-use code
2. AnyOAuth issues a short-lived profile token
3. Backend fetches the signed-in identity

The returned token belongs to AnyOAuth. Its permitted resource is the profile, not Google or GitHub APIs.

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.

<figure class="article-diagram"><ol><li><strong>During the handoff:</strong> use the profile token to retrieve identity.</li><li><strong>After identity resolution:</strong> issue your application's session and revoke the now-unneeded profile token.</li><li><strong>On later requests:</strong> validate your application's session, not the old profile token.</li></ol><figcaption>Profile-token lifetime and application-session lifetime are independent clocks.</figcaption></figure>

## 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](/blog/what-is-oauth/). For the application-facing flow, read [redirect, exchange, profile](/blog/redirect-exchange-profile/). For the step after it, read [your app owns the session](/blog/your-app-owns-the-session/).

## Sources and implementation references

- [AnyOAuth quickstart](/docs/) and [security model](/security/), reviewed 2026-10-06.
- [RFC 6750: OAuth 2.0 Bearer Token Usage](https://www.rfc-editor.org/rfc/rfc6750.html), retrieved 2026-10-06.
- [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700.html), retrieved 2026-10-06.