- accounts (personal)
- orgs (companies, directories, teams, roles etc.)
- enterprises (sets of orgs)
Even with enterprise SSO, the initial connect to GH can (is typically) "you" (just as you have the same driver license to show at the front desk when registering to visit a secured firm or random hotel), then you elevate "you" into the org through SSO, and what policies apply to you via your org can be 'governed' at the enterprise.The idea behind this model is that no, you don't have to manage lots of those as you, you're just you, and each of those you aim to use has an elevation that entity controls instead of you controlling it.
This ultimately results in way less key material floating around, and you losing, leaking, or lousing up your own GH cred doesn't auto-give an attacker the SSO elevation.
• • •
Not incidentally, I have a slew of "accounts" given to me by companies that don't bother to make an org, they just invite individuals to repos or make individual accounts for their repo. I suppose it's cheaper in the short run. In the long run, these accounts are 90% still left active years to (no kidding) decade+ later. Seems a better idea to "don't do this." If you're a company, be an org.
---
* Expanded for more depth: https://docs.github.com/en/get-started/learning-about-github...
Is there any good reasons not to separate what you work on into multiple GitHub accounts? Not to mention some people don't want all their projects attached to one profile, some people also develop in their free-time, and don't want to mix freetime/work projects under the same user account, for multiple reasons.
If they used their personal account for both, it could be unclear if they speak on behalf of our company or not.
B if you ever be in a company using the half baked GitHub hosted enterprise….