Cannot resume GitHub operations when SAML SSO auth is required on PATs

[mjcheetham]

When an organisation has enabled and requires SAML SSO in order to access their repos, and we are using PATs, it is not possible to use the generated PAT because it is lost/never stored by GCM Core.

Normally we'd expect Git to tell us explicitly if a given PAT should be stored or erased after we return from a get.
However when a PAT requires SSO be enabled manually on the web, GitHub returns a 403 to which Git does nothing except print the remote: SSO required message.

Ideally we would want Git to tell us about the 403 and that the PAT was for a valid user, but lacked the specific permissions. That way we could store it and direct the user to update/change the PAT permissions, or even fix them automatically for them.

In the meantime, to workaround this we should store the PAT once we generate it. This means that when users who hit this scenario, they can come back and retry with the same PAT after enabling SSO permissions.

This workaround does break another scenario however - if the user has manually changed the permissions of the generated PAT in the web, then GCM will not prompt to generate another PAT since it always finds the existing 'bad' PAT and Git never tells us to erase it. Since this is a scenario where the user has 'done the wrong thing', it is a smaller and more unlikely situation than a user needing the SAML SSO approve their PATs.

[mjcheetham]

It should also be mentioned that using the OAuth route does not have the same issues, once OAuth is ready for primetime.

[mjcheetham]

We've hacked around this by storing the PAT on get when we know the PAT is good (even if not SSO enabled). This means that the PAT is not lost before the user does the manual interaction to enable SSO.

Since the 'better' fix here is actually just moving to OAuth as the preferred/default authentication mechanism, I'll close this issue.