能否在Git托管服务上层搭建带MFA的用户账户管理系统？

技术上完全可行，不需要修改Git原生客户端，也不需要深度侵入改造GitHub、GitLab、Gitea的核心代码，最终可以做到用户执行Git远程操作的交互流程和平台原生MFA访问完全一致，目前已经有不少企业内部的Git统一身份管控方案是按这个逻辑落地的。

整套方案的核心是在用户和Git托管服务之间加一层透明的身份认证代理，把MFA校验能力嵌在代理层即可，不需要改动后端托管服务的原有逻辑：

• 代理层需要同时兼容Git的两类主流认证协议：HTTPS协议下的用户名/令牌认证流程、SSH协议下的公钥认证流程，保证所有原生Git操作的请求都能被正常拦截、透传。
• 用户首次发起Git远程操作触发认证时，代理层会拦截未认证的请求，跳转至自建账户系统的MFA校验环节，支持TOTP动态码、硬件安全密钥、短信/邮箱验证码等任意需要的MFA校验因子，校验通过后，代理层再通过预先对接的平台接口，换取对应仓库访问权限的临时凭证，和后端的GitHub/GitLab/Gitea完成认证交互，把用户的Git请求正常透传给后端服务。
• 体验对齐原生MFA的关键是做好认证状态缓存：MFA校验通过后，给用户客户端签发和原生格式完全一致的短生命周期访问凭证——HTTPS场景下就是符合平台规则的临时个人访问令牌（PAT），SSH场景下就是短时效的SSH访问证书，凭证有效期内用户执行pull/push/clone等操作不需要重复触发MFA校验，和原生MFA的“信任设备”免校验逻辑完全一致。

• GitHub、GitLab这类公有云/官方托管的服务：本身开放了完整的管理API、OAuth2授权接口、SSH证书签发能力，不需要修改平台任何代码，直接对接官方开放接口就能实现动态凭证签发、细粒度权限管控、凭证自动回收，甚至可以做到比原生MFA更细的权限颗粒度，比如限制用户只能访问特定仓库、只有推送权限没有删除权限等。
• Gitea这类开源自托管服务：除了走前面说的代理层方案，还可以直接把自建的带MFA能力的账户系统对接为Gitea的外部身份源，简单修改配置就能实现完全原生的认证体验，连代理层都不需要部署。

要做到和原生MFA访问无感知，只需要注意两个点：

• 不要要求用户安装额外的Git插件或者自定义客户端，所有认证逻辑都要兼容原生Git的认证流程，用户用系统自带的Git命令就能完成所有操作。
• 可以把代理层配置为Git服务域名的透明入口，用户手里的仓库远程地址不需要做任何修改，操作时甚至感知不到中间有一层独立的账户管理系统。

内容的提问来源于stack exchange，提问作者Rainbow