2FA, SSO, policies, least privilege

Why this matters

Security settings on the platform are chosen by someone else and change how your tools behave. The two that surprise people most are two-factor authentication, which makes account passwords useless for Git, and single sign-on, which quietly requires an extra click on every new token. Both produce errors that look like your mistake.

Two-factor authentication

That last point is the practical consequence, and GitLab says it in the error message itself:

remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password.

Enable 2FA anyway; most organizations require it. Then use a token (lesson 8.3) or an SSH key (lesson 8.2), which are unaffected by the second factor because they are the second factor's replacement for machines.

Single sign-on

Larger organizations put GitLab or GitHub behind their identity provider (Okta, Entra ID, Google Workspace), so you sign in with your company account. Two things follow that regularly confuse people:

• Sessions expire on the company's schedule. You may be signed out of the website daily; that does not affect an already-stored Git token.
• Tokens and SSH keys need authorizing for the organization. On GitHub with SAML SSO, a new token works for your own repositories but is refused for the organization's until you authorize it: the token page has an Authorize or Configure SSO control next to each token, and the same applies to SSH keys. Missing this step produces a permission error that looks exactly like a scope problem.

If a token with the right scopes is refused for an organization's repository and works for your own, SSO authorization is almost always the reason.

Organization policies you will meet

You cannot change any of these; a maintainer, owner or administrator can. Knowing they exist means you recognize a policy at work rather than assuming your setup is broken.

Least privilege

The habit that makes all of this easier: ask for the smallest access that lets you do the work, and grant the same when it is your turn.

• Roles: Developer (GitLab) or Write (GitHub) is enough to branch, push and open merge requests. Maintainer is for people who own the branch protection and the merge button (lesson 1.8).
• Tokens: repository scopes, not api; one repository, not all of them.
• Duration: a shorter expiry costs you one renewal a year and shrinks the window in which a leaked token is useful.
• Ownership: automation gets a project token, not yours.

The reason is not bureaucratic. Every credential is a thing that can leak, and its scope decides how bad that day is.

Common mistakes

• Treating the 2FA message as a password problem. It is telling you to use a token.
• Forgetting SSO authorization for a new token or key. Works for personal repositories, refused for the organization's.
• Storing recovery codes on the phone that holds the authenticator. Lose the phone, lose both.
• Asking for Maintainer "to save time". More responsibility, more ways to break a shared branch, and usually a slower approval than asking for Developer.
• Sharing a token with a colleague. Their actions then appear as yours. They should have their own.