未上线网站配置GitHub OAuth及相关技术问题咨询

完全不需要先上线网站，有两种可靠的测试方式：

• 使用localhost作为回调URL：GitHub允许将http://localhost:端口号（比如http://localhost:3000/callback）直接填为OAuth应用的回调地址。测试时在本地启动服务，用户在浏览器完成授权后，GitHub会将授权码重定向到本地的回调接口，全程不需要公网。
• 采用设备授权流（Device Flow）：如果你的应用是桌面端、CLI工具这类没有回调能力的场景，GitHub支持Device Flow。流程是：应用请求GitHub生成设备码和用户验证URL，用户在任意浏览器打开该URL并登录授权，应用轮询GitHub获取access token，全程不需要回调URL。

与Google OAuth的核心差异 #

1. 回调URL灵活性：GitHub直接支持localhost作为回调地址，无需额外配置；Google OAuth虽然也支持localhost，但需要在OAuth同意屏幕中添加测试用户，且公开应用的回调URL必须是HTTPS（除了localhost）。
2. 授权流适配场景：GitHub的Device Flow对非Web应用更友好，配置简单；Google的Device Flow主要针对IoT设备，配置和流程相对繁琐。
3. 权限范围设计：GitHub的scopes围绕代码仓库、用户资料、组织权限等开发场景（如repo、read:user）；Google的scopes覆盖旗下所有服务（如gmail.readonly、calendar.events），分类更细。
4. 应用审核机制：GitHub公开OAuth应用只需填写基本信息即可上线，审核宽松；Google公开应用需要经过严格的安全审核，包括隐私政策、使用场景说明等，周期较长。

GitHub OAuth可获取的用户/资源信息 #

根据申请的权限范围（scopes）不同，可获取的信息包括：

• 基础用户信息：通过read:user scope获取用户名、头像、个人简介、创建时间等公开资料；user:email可获取用户邮箱（包括未公开的邮箱）。
• 仓库权限：repo scope允许读写用户的公开/私有仓库，包括代码、issues、pull requests等；public_repo仅能访问公开仓库。
• 组织与团队：read:org可获取用户所属组织的基本信息，write:org能管理团队成员和权限。
• 其他资源：gist可操作用户的Gist，notifications能访问用户的GitHub通知，admin:repo_hook可管理仓库Webhook等。

GitHub API OAuth应用速率限制说明 #

OAuth应用的15000次/小时请求限制是应用级别的全局限制，具体规则：

• 这个限制针对你的OAuth应用本身，而非单个授权用户。所有通过该应用授权的用户发起的请求，都会计入这15000次的总量。
• 对比个人访问令牌（Personal Access Token）的5000次/小时用户级限制，OAuth应用的限制更高，适合服务多个用户的场景。
• 当请求超过限制时，GitHub API会返回403 Forbidden响应，同时在响应头Retry-After中告知需要等待的秒数。
• 未授权的请求（仅用客户端ID）速率限制为60次/小时，远低于OAuth授权后的请求限制。

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