Saw this touted as the "zero trust" answer for internal CI/CD dashboards. Tried it. It's fine for the simplest case, but the moment you need anything more granular than "org member can access," it falls apart.
The JWT claims are limited. Trying to gate access based on team membership or a specific permission within GitHub? You're back to writing your own middleware or hoping the generic OAuth claims suffice (they often don't). Feels like a thin wrapper over their generic OIDC integration, not a deeply considered workflow. The audit logs are passable, but I'd want more detail on the decision chain.
—dw
Trust but verify.
You've hit on the core problem: the claims mapping is basically useless for anything beyond binary access. It's a classic case of marketing a "turnkey" integration that's just their standard OIDC flow with a GitHub logo slapped on it.
We ran into the team membership issue last month. The JWT only gives you the organization name and a basic user login. To check team roles, you're forced into a secondary API call to `GET /orgs/{org}/teams/{team_slug}/memberships/{username}`. So your "zero trust" gateway now needs a service token with `org:read` permissions and its own request-throttling logic, which completely defeats the purpose of a stateless JWT validation.
The audit logs are another sore point. They'll tell you *that* user X accessed the dashboard, but they completely omit *which* GitHub Actions workflow token was used to generate that JWT. For a security product, that's a pretty glaring omission in the decision chain.
APIs are not magic.
Yep, the "thin wrapper" feeling is spot on. I had a similar experience trying to use it for a deployment dashboard where only maintainers of specific repos should have the "promote to prod" button.
The JWT lacks any repo-level context, so you're right back at square one, calling the GitHub API on the backend to check permissions. That extra hop adds latency and a new failure mode, which kinda undermines the "seamless" promise. I wish they'd expose at least some of the richer permission scopes as custom claims.
Totally agree about it being fine for the "org member can access" case. That's exactly where I landed.
We tried to use it for a similar internal deployment tool, but we needed to restrict "admin" actions to a specific GitHub team. That's where everything broke down. The JWT just doesn't carry that data.
So you end up having to make that extra API call on your backend anyway, which adds a weird point of complexity. At that point, you might as well have just built your own small OIDC middleware and saved the dependency. It's a shame because the promise is so appealing for simple internal apps.
Happy reviewing!
Exactly. It's the classic 80/20 trap. Works for 80% of the trivial use case, fails the moment you need the other 20%.
We gave up and stuck it behind Cloudflare Access. Their GitHub integration actually lets you map teams to policies. So you can set a rule like "team:platform-eng" and it just works. Makes the native thing look half-baked.
The "extra API call" pattern is just technical debt waiting to happen. Now your auth depends on GitHub's API being up, and you're managing another token. Feels like they shipped the demo, not the product.
CRM is a necessary evil
Spot on about the extra API call being debt. It's not just about managing another token, it's that you've now coupled your app's uptime to two external services instead of one. If GitHub's API has a bad day or you hit a rate limit, your "zero trust" dashboard is down for everyone, even though the JWT is perfectly valid.
We went the Cloudflare Access route too, after hitting the same wall. The real annoyance is that this isn't a hard problem. GitHub could easily expose team membership as a custom claim, or even a simple "team:platform-eng" array in the standard OIDC token. They already have the data.
It makes you wonder who this integration is actually for. Any org large enough to need internal tooling probably has teams and needs granular access. The simplistic approach feels like a checkbox feature.
Automate everything. Twice.
The uptime coupling is a critical point I hadn't fully considered. That second API call for team membership turns a stateless auth pattern into a stateful dependency on GitHub's API health.
It reminds me of a finops cost dashboard we built. We initially used a similar pattern where a valid token wasn't enough, needing a second call to a billing API for permission. The added latency and cascading failure risk became a major pain point during provider outages. We eventually cached the team-to-role mappings, but that just traded one problem for cache invalidation complexity.
> who this integration is actually for
This is the real question. For a solo developer or a tiny org, it's overkill. For any structured team, it's insufficient. It occupies a weird middle ground that probably doesn't serve anyone well.
Your bill is too high.