Discover how experienced DevOps teams tackle the real-world security challenge of revoking OAuth permissions for offboarded employees, moving beyond academic examples to enterprise-grade, automated solutions.

So, You Revoked an OAuth App in Class. Here’s How We Handle It When Millions Are on the Line.

I still remember the “Ghost of Jenkins Past.” It was a Tuesday. A frantic message pops up—our main deployment pipeline is failing with bizarre permission errors. After an hour of digging, we found the culprit: the pipeline was authenticated to GitHub using an OAuth token from an engineer… who had left the company two weeks ago. His permissions were revoked in our Identity Provider, but that long-lived token was still chugging along inside our CI/CD system, a digital ghost with just enough access to break things but not enough to do its job. That day taught me a lesson that no textbook can: offboarding is not just about disabling a login.

The Core Problem: A Token is a Promise, Not a Conversation

So why did this happen? When a user grants an application access via OAuth, the app gets a token. Think of this token like a temporary keycard. The app presents this keycard to the service (like Google’s or GitHub’s API) to get access on the user’s behalf. The critical part is that, by default, the service trusts the keycard until it expires. It doesn’t constantly run back to your company’s directory to ask, “Hey, is Darian still an employee?” The token is a bearer token—whoever holds it, bears it, and can use it. Revoking the user’s main login doesn’t automatically invalidate that keycard they already handed out.

How We Tackle This in the Trenches

In a real production environment, we can’t just hope for the best. We have a playbook with a few different approaches, ranging from a quick fix to a full-blown automated system.

Solution 1: The “Find and Destroy” Mission (The Quick Fix)

This is the manual, brute-force approach you take when the fire alarm is ringing. It’s what we did with the Ghost of Jenkins Past. You identify the compromised user and the application, log into the service as an admin, and manually revoke the specific token or application grant.

For example, in GitHub, an organization admin can go to a user’s profile, navigate to Applications > Authorized OAuth Apps, and hit “Revoke.” It’s effective for a single incident but completely unsustainable at scale.

If you’re lucky, the service has an API for this. We have a break-glass script that does something like this (conceptually):

# THIS IS A SIMPLIFIED EXAMPLE
# Assumes you have API access and know the grant ID

API_TOKEN="your_admin_api_token"
GRANT_ID="the_offending_grant_id_to_revoke"

curl -X DELETE \
-H "Authorization: bearer ${API_TOKEN}" \
"https://api.some-saas.com/v1/applications/grants/${GRANT_ID}"

echo "Grant ${GRANT_ID} has been nuked."

Pro Tip: This is a reactive solution. It’s what you do when your process has already failed. Don’t rely on this as your primary strategy; it’s a bandage, not a cure.

Solution 2: The SCIM Reaper (The Permanent, Automated Fix)

This is the real answer. This is how you sleep at night. We integrate our central Identity Provider (IdP), like Okta or Azure AD, with our critical SaaS applications using a protocol called SCIM (System for Cross-domain Identity Management).

Here’s how it works:

• When our HR system marks an employee as “terminated,” it signals our IdP.
• The IdP, which is the source of truth for all identities, immediately deactivates the user’s account.
• Thanks to SCIM, the IdP then sends an automated de-provisioning signal to all connected applications (GitHub, Slack, AWS, etc.).
• The application receives this signal and is configured to automatically:
  • Deactivate the user’s account.
  • Invalidate all active sessions.
  • Revoke all issued OAuth tokens and API keys associated with that user.

This is the “set it and forget it” gold standard. The moment a user is offboarded from one central place, their access across the entire digital estate evaporates automatically. No scripts, no manual searching, no ghosts in the machine.

Solution 3: The “Scorched Earth” Protocol (The Nuclear Option)

Sometimes, you can’t find the token, or you suspect a wider breach. Maybe an application’s credentials themselves were leaked from a build server like `ci-runner-prod-03`. In this case, you don’t hunt for one bad keycard; you change the locks on the entire building.

The “nuclear option” is to rotate the application’s client secret within the OAuth provider’s settings. A client secret is the password for your application itself. When you rotate it, you are effectively telling the provider, “Any token that was issued using the old secret is now invalid.”

This forces every single user of that application to re-authenticate. It’s disruptive and can cause a temporary outage for your users, but it guarantees that any and all old, potentially compromised tokens are instantly rendered useless.

Warning: This is not a casual Friday afternoon task. It requires coordination. You must update the new client secret in your application’s configuration (`prod-app-secrets.yml` or your secrets manager) at the same time you rotate it. Failure to do so will break your application’s authentication flow entirely.

So, while it’s cool that your professor showed you the “revoke” button, the real challenge isn’t knowing how to click it. It’s building a system where you never have to.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions