OAuth tokens unexpectedly revoked with max_for_app on every login

[jihye1]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Apps

Body

Hello,

I am running into an issue where GitHub unexpectedly revokes and regenerates OAuth app tokens on every single login attempt, specifically for a certain enterprise email domain.

According to the GitHub documentation (https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#creating-multiple-tokens-for-oauth-apps), GitHub allows up to 10 tokens to be issued per user/application/scope combination. If the 10-token limit is exceeded, the oldest token should be revoked.

However, instead of maintaining multiple tokens up to the documented limit of 10, each new login triggers a sequence of oauth_access.create, oauth_access.destroy, and oauth_access.regenerate actions. This causes unexpected logouts and session expirations for users who work across multiple devices. It appears that the existing active token is being destroyed immediately upon a new login, rather than destroying the oldest one.

I tracked this behavior via the GitHub Security log (https://github.com/settings/security-log). When a GitHub account under the affected enterprise email domain logs in, the following event occurs:

• Action: oauth_access.destroy
• Event text: Revoked a token for jihye1 ending in g2..... for the DeepScan OAuth app.
• Explanation: max_for_app

Related Link

I found a GitHub CLI issue that mentions a similar unexpected behavior regarding token management: cli/cli#12490

Questions

1. Does the GitHub system enforce stricter OAuth token lifecycle criteria (e.g., limiting tokens to 1, or forcing immediate revocation of previous tokens) specifically for enterprise-managed email domains?
2. If this is an intended security behavior, is there any configuration or setting we can modify in our OAuth app to allow multiple tokens for these users?

Thanks,
Jihye

[Hemu2174]

Hi Jihye,

What you're describing does not match the documented behavior for standard GitHub OAuth Apps, where up to 10 active tokens can exist per user/application/scope combination before the oldest token is revoked.

A few observations:

• The oauth_access.destroy event with the reason max_for_app suggests GitHub believes the token limit for that user/app combination has been reached.
• If a newly created token immediately causes the previously active token to be revoked, that may indicate a different token policy is being applied than the standard 10-token behavior described in the documentation.
• I am not aware of any public GitHub setting that allows OAuth app developers to configure the maximum number of active OAuth tokens per user.
• I am also not aware of documentation stating that enterprise-managed email domains automatically enforce a single-token limit. However, enterprise security controls, SAML/SSO integrations, managed users, or internal GitHub policies could potentially affect token lifecycle behavior.

To help narrow this down, I would recommend checking:

1. Whether the affected users are Enterprise Managed Users (EMU) or are subject to additional enterprise security policies.

2. Whether SAML SSO enforcement or other enterprise authentication controls are enabled.

3. Whether the behavior reproduces with:

   • a personal GitHub account,
   • a non-enterprise email account, and
   • the same OAuth application and scopes.

If the issue only occurs for accounts associated with a specific enterprise domain while standard accounts retain multiple tokens, that would strongly suggest an enterprise-specific policy or GitHub-side restriction.

Since the behavior appears to differ from the public documentation, opening a GitHub Support ticket with:

• the OAuth app name,
• affected account examples,
• timestamps from the security log,
• and the oauth_access.destroy (max_for_app) events

would likely be the best path to determine whether this is intended behavior, an enterprise policy interaction, or a platform bug.

I'd be very interested to hear what GitHub Support confirms, as this behavior appears inconsistent with the documented 10-token limit.