Start Up Travel - OAuth

前言 此文专注于解决从工程上接入第三方 OAuth 登录可能遇到的困难。OAuth 的原理并不在讨论范围中,如果阁下想要了解 OAuth 的原理,请参考 Wikipedia OAuth 和 [筆記] 認識 OAuth 2.0:一次了解各角色、各類型流程的差異。 本文以 Go 后端接入 Github、Facebook、Twitter、Apple、Google 五家的 OAuth 为例。 接入 OAuth 的困难之源 OAuth 对于开发者是一个有一定标准的黑箱,它遵从一些基础逻辑,但如果要让其正常工作,需要付出不少努力。 虽然,OAuth 有一个相对规范的标准流程,但是各家提供商因为安全因素在内的各种原因,导致具体的实现大不相同。 而在后端工程中接入 OAuth 又需要工程师尽可能抹平这些差异性,给前端提供一致的接口。 前端,也可能因为一些奇特的业务需求,如 Native App 使用 Web OAuth,而遇到不少新麻烦。 于此同时,运维还需要跟各家提供商的 OAuth Secret 申请流程和管理界面打交道,这里每一家的申请流程和管理界面都有不同的交互逻辑和限制,也使得相关工作富有挑战性。 准备工作的困难 千奇百怪的申请流程 各家提供商的 OAuth 申请流程都是不同的,虽然各家都提供了自己的申请文档,但是找到各家的文档本身就不是一件容易事。而且因为各家提供商都用自己的行文逻辑去编写自家文档,所有有较大的理解成本。 笔者采用的逃课方式是,全部查看 supabase 的 Auth 文档,supabase 重写了一遍申请流程,逻辑更清晰,同时行文逻辑统一。(同时在这里推荐大家 side project 可以去白嫖 supabase 提供的数据库) 同时,在申请时各家提供商还有需要各自需要注意的地方。 Twitter Developer Account 只有一次申请机会,申请失败了,就永远没有下一次机会了,请好好写你的英语小作文。(曾经开放的 twitter 已经离我们远去了) Apple OAuth Secret 的申请流程非常复杂,但是跟着 supabase 的文档一步步走不会有错。同时一定要注意,Apple 的 OAuth Secret 有有效期限制,最多 180 天。 如果在生成 Secret 时填写超过 180 天的有效期不会报错,但是会在使用时收到如下,非常迷惑的报错。...

Hexagram