如何安全地在浏览器端代表用户调用GitHub API？

哥们，你这个需求其实挺典型的——已经搞定了服务器端的OAuth令牌，想直接在浏览器调GitHub API省掉后端代理的开销，但又怕短期令牌存在前端不安全。结合GitHub的机制，我给你几个靠谱的解决方案：

• 方案一：用PKCE流程直接在前端拿短期令牌，后端存刷新令牌
  你可以调整现有的OAuth流程，采用GitHub专门为单页应用设计的**PKCE（Proof Key for Code Exchange）授权码流程**。前端先生成一个随机的code_verifier，再通过它生成code_challenge，然后带着这个code_challenge去GitHub请求授权码；拿到授权码后，前端配合后端（或前端直接）去GitHub兑换短期访问令牌（还是8小时有效期），同时后端会拿到一个刷新令牌。
  平时前端把短期令牌存在内存里，直接调用GitHub API；令牌过期后，前端请求后端，由后端用刷新令牌去GitHub换一个新的短期令牌再返回给前端。这种方式既省了后端代理的额外开销，又避免了长期存储令牌的风险——页面刷新后重新从后端拿就行。

• 方案二：基于GitHub App生成用户级短期令牌
  你提到的App JWT是应用自身的权限，但其实GitHub App支持生成用户访问令牌——这是完全代表用户的令牌，权限和用户自己授权的一致，而且有效期可以设置得更短（最长1小时），安全性更高。
  流程是：用户授权你的GitHub App后，后端用App的私钥生成一个JWT，然后用这个JWT为该用户创建一个短期的用户访问令牌，传给前端使用。令牌过期后，前端再请求后端重新生成一个。这种方式的好处是令牌权限完全映射到用户，不会和应用权限混淆，而且短有效期就算泄露，影响范围也很小。

• 必注意的安全细节
  不管选哪个方案，这些安全红线不能碰：

  • 前端的令牌只存在内存中，绝对别存localStorage或sessionStorage，防止XSS攻击窃取令牌；
  • 所有请求必须走HTTPS，避免令牌被中间人劫持；
  • 给令牌设置最小权限scope，比如只申请repo、user:email这类你实际需要的权限，不要贪多申请全量权限；
  • 配置GitHub OAuth的授权回调地址时，严格限制为你的前端域名，防止回调地址被滥用；
  • 后端在生成或刷新令牌时，一定要验证用户的身份（比如用后端的session或用户凭证），确保令牌只发给合法用户。

备注：内容来源于stack exchange，提问作者CordlessWool