Sign in as anyone: Bypassing SAML SSO authentication with parser differentials

GitHub's SAML implementation is useless. The idea is that you can bring your own account into an enterprise, and that sort of works on the site itself, but it does not prevent apps where you log in with GitHub from reading your organization membership once you have authorized an app on the organization level (and if you didn't, it hides the membership from oauth tokens, so it has this capability!).

A SAML session is only required if said app fetches data via a token obtained from that user - and in my glance around, this was almost never the case - SAST tools almost always use app instance tokens and are happy to show anyone with a GitHub account in your organization your code. Tailscale fixed this when I pointed it out, Sonarcloud told me to please don't tell anyone and GitHub took a few weeks to say this is totally expected behavior - when no vendor I told did, and their docs contradicted them.

I swear, reporting security bugs is a thankless endeavor, even if you just randomly stumble over them. I couldn't imagine doing this as a job.

> The idea is that you can bring your own account into an enterprise

The issues goes beyond authorization. I’ve had Github randomly once in a blue use my personal email address as the default when merging a work PR. If anyone asks, I advice against mixing personal and professional stuff in the same Github account (or anywhere).

My company does not allow any employees to use their personal GitHub for work (or Facebook, instagram, or anything else) after running into issue when employees leave.

Wouldn’t you just remove them from the org?

They may decide to change their github login to <company_name>LIES, and suddenly that’s all over your old PRs and Issues. Including in public repos where customers go looking for help.

That's even more true with a dedicated work github account than a mixed personal/work one; either way they can still login and edit the account name even if removed from the company org, and if it's not shared it doesn't burn their personal account too... right?

Is this speaking from experience?

With a dedicated work account the organization can always take over the account (via reset email if need be, since they own your work email account) and do whatever they want with it

A dedicated work account _where you use your work email address_... that was the missing part throughout this thread.

But then if you do that you also lose all your open source work history, which is important from a hiring/resume perspective.

One option for those so inclined is to cryptographically sign commits with a key that lists both work and personal email address (assuming your enterprise’s policy allows it). The employer retains control but you have a claim to credit for your work.

If we're discussing companies willing to go to lengths to scrub you from their GitHub history, they can still replace all commits you've signed with new commits. You likely have no legal rights to that work, and git does allow you to rewrite history arbitrarily.

> git does allow you to rewrite history arbitrarily.

Technically yes, but the price is too great - everybody who has cloned the repos will now have to nuke their local copies too.

Sure, but the same is true for unsigned commits as well, isn't it? Or can you modify the commit metadata without changing the commit hash in those cases?