实现 Authing/Okta/Auth0 的难点在于？为什么这块还需要云服务？
annoygaga · 2024-01-22 11:57:10 +08:00 · 8978 次点击这是一个创建于 366 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，题主在思考为什么用户这种最重要的数据需要外包给 SaaS 服务，这块服务的痛点在哪里呢？
 |
1
param 2024-01-22 12:01:26 +08:00 via Android
有人回应的话 @下我，也想知道其他人怎么答
|
 |
2
drymonfidelia 2024-01-22 12:04:58 +08:00
自己写要自己保证数据不泄露服务不出 bug 不爆炸，要自己接风控
接 saas ，泄露了也不是只泄露自己一家方便甩锅，成本比自己的程序员还低 |
 |
3
Casbin 2024-01-22 12:11:18 +08:00
如果问出这个问题，说明你是有技术的，这个东西对你没难度。没难度会搭建的话，用开源就行： https://v2ex.com/t/803669 ，当然自己写一套简单的也可以，可能用着更顺手
|
 |
4
stimw 2024-01-22 12:12:24 +08:00
1. 节省开发、维护工作，能专注业务逻辑，甚至配合一些全栈框架能光速上线产品。
2. 实际上外包费用在业务初期阶段并不高。 3. 方便甩锅。 |
 |
5
Perry 2024-01-22 12:28:41 +08:00 via iPhone
用户最重要的数据你确定是存在这些服务那？
|
 |
6
keepRun 2024-01-22 12:34:00 +08:00 via Android
能够快速上线就是他的优势
|
 |
7
iseki 2024-01-22 12:34:53 +08:00
有些不想自己针对这块造轮子，主项账号数据这个东西你说它重要吧，它确实重要，但是它往往和核心业务关系不大。至于难点，只能说业务上想把任何一个东西做好都难，无非就是你怎么定义“好”了。
|
 |
8
javalaw2010 2024-01-22 12:41:43 +08:00
浪费时间，把这块写好其实是要费不少时间的，特别是对小团队来讲很耽误快速试错的节奏，你注意看的话现在很多小团队的 APP 直接把 Auth 这块砍了，资产直接跟着设备走。
|
 |
9
shyling 2024-01-22 12:42:14 +08:00
自己做的话，每对接一个单点登录就都是风险点啊，但假如用 saas ，你自己就只需要对接一个了，后续新增支持渠道也不太需要自己动手。
出了问题也更好甩锅，反正用 xxxx 不止我们。 |
 |
10
sxyclint 2024-01-22 12:46:54 +08:00
通常 IAM 的 SaaS 也有私有化部署服务，数据也可以不出企业。
另外，人家是专门做这个卖这个的，自己做不过就是再重复造轮子造一遍，从时间和最终效果上大概率比不上，更不要提后期维护和定制这些，这东西本身也没什么太大的技术壁垒。 如果你是自己的企业自己的系统也确实没必要，如果你的产品本来要是作为服务售卖的，找这个能帮你解决客户无止境的定制问题。 |
 |
11
matrix1010 2024-01-22 12:51:14 +08:00 via iPhone
真正做起来东西很多，比如各种 oidc 登陆以及 email 登陆，处理账号关联，修改重置密码，修改邮箱等。另外还有 web 端 cookie ，cors 处理之类的。建议完全看一遍 auth0 的文档，或者开源的 ory kratos 之类的，你就会感受到整套的 auth 系统有多复杂
|
 |
12
annoygaga OP |
|
13
annoygaga OP @Casbin 自己实现过 jwt/session 等，也用过各种语言的框架内的用户系统，用户应该蛮重要的，所以我很不理解这个
不过说起来 auth0 这些还提供了什么呢？或者实现一个的难点在于？（我指的是 auth0 系统，不是某个 app 的用户系统） |
|
15
annoygaga OP |
|
18
annoygaga OP @javalaw2010 但后期迁移成本也非常高呀，而且很多业务都是跟着用户体系走的，这个都不用长期，早期就得耦合很多代码
|
|
20
annoygaga OP @sxyclint 主要还是定制化这块，很多业务逻辑跟着用户体系走，都不用长期，早期可能就得写一些代码耦合这些 IAM
|
|
21
annoygaga OP @matrix1010 有什么开源的实现推荐，或者什么资料吗？我现在确实想完整看完学习一下
|
|
22
drymonfidelia 2024-01-22 13:27:44 +08:00
@annoygaga 有空考虑这么多的时候你肯定已经赚够钱了，直接找 saas 的商务谈，钱够什么功能都能给你弄出来，不要尝试用技术解决非技术问题
|
|
23
matrix1010 2024-01-22 13:28:19 +08:00
@annoygaga https://www.ory.sh/docs/kratos/ory-kratos-intro, kratos 是核心部分，ory 还有 hydra, oathkeeper 这些其他组件也可以看看。开源的好处是可以边看文档边看代码
|
|
24
matrix1010 2024-01-22 13:31:28 +08:00
|
|
25
matrix1010 2024-01-22 13:36:54 +08:00
其实核心在于 auth 本身是解耦的，在业务端可能只需要一个 id ，或者 jwt 里的 sub 。因此很适合单独做成服务。另一个就是正确，安全而且高效的实现 auth 并不容易，在程序员人手/水平不足的情况下使用现成服务更加合适。比如很多 gpt 套壳网站/应用，整个功能加起来可能都比 auth 简单很多
|
 |
26
Mithril 2024-01-22 13:52:46 +08:00  1
对于一个商业产品来说，“成本”并不只有开发和运行成本，也要包括审计合规，法务，数据保护等等。
而 auth 这东西就属于，你不能没有，开发起来难度也不高，但合规处理非常麻烦，想要防御针对性攻击更加麻烦，同时也不是核心的业务数据资产。 对于大多数业务模型来说，用户这东西只要是个唯一 ID 就行了，至于他叫什么名字，用什么邮箱并不是很重要。 而合规这玩意，不同国家地区的法律并不相同。虽说很多时候你的业务数据可能也算需要做合规审计的用户数据，但 auth 里面的东西一定是要做合规的。 对于一个风险很高，法务处理很麻烦，又不是很重要的东西，最好的选择自然就是外包了。 让第三方去提供各种合规审计，各种防护措施。远比你雇一整个团队去做更省成本。 |
 |
27
cktsun 2024-01-22 13:58:06 +08:00 via Android
這個問題就像問一些大公司為何要用 Cloudflare 一樣
|
 |
28
ck65 2024-01-22 14:02:19 +08:00 2
中小企业试错啥的，这种用户根本不产生什么收入，免费套餐吃到撑，属于欢迎来玩、祝您成功这类的。真正产生收入的是为了降低合规成本不得不把用户平台包出去的大企业，用买来的方案把 ISO 27001 、GDPR 之类的破玩意一口气全搞定，专心做业务和对付其他破事。所以「为什么这块还需要云服务？」没啥为什么，就是企业到了一个点之后用它就划算。
PS：根据官方信息，Auth0 过去经历的十轮融资止步于 2020 年，可以怀疑资本也产生类似 OP 的疑问了。 |
 |
29
nuII 2024-01-22 14:21:18 +08:00
对业务来说，在预算范围内能花钱解决的，都比自己干要好，赚钱的是业务带来的收益，而不是你的代码有多牛比
|
|
30
annoygaga OP @drymonfidelia 那比如说一些框架内内置的用户呢？比如典型的 Django 和这些的对比
|
 |
31
0o0O0o0O0o 2024-01-22 14:24:33 +08:00
> 难点在于？
The devil is in the details. > 自己实现过 jwt/session 等，也用过各种语言的框架内的用户系统 推荐一篇文章，只吐槽了其中很小的一方面 https://x.com/Komodosec/status/1718028445299642562 |
|
32
annoygaga OP @matrix1010 感谢
|
|
33
javalaw2010 2024-01-22 14:25:14 +08:00
@annoygaga #20 小公司活着已经很难了，这个月通常想的是下个月的事而不是明年甚至 5 年以后得事，真的赚到钱了在渐进式迁移回来也不迟。至于业务上的耦合很容易解决，提供接口给业务系统获取用户信息，业务系统根据自己的需求保留最小的用户信息丢到自己的表里。我们自己内部就有一个类似的 sass 平台提供类似 Auth0 的能力，当然我们是小公司所以只能最精简实现，在 sass 平台眼里估计连个 demo 也算不上，但管他呢，能用就行。
|
|
34
annoygaga OP @0o0O0o0O0o 感谢，我学习学习
|
|
38
annoygaga OP @javalaw2010 嗯，其实我不是没用过这些，这些使用体验并没有想象中那么好，而且还存在一定的学习成本（比如各家都有各家的 SDK blabla ）
|
 |
39
Lockeysama 2024-01-22 16:14:00 +08:00
经历过，原因其实挺简单的，有些客户要求安全等级高，不信任自己开发的用户系统，要求接入像 Auth0 这样的他们信任的系统。
|
|
40
annoygaga OP @Lockeysama 嗯嗯，所以想技术上来说，实现难点是？
|
 |
41
fkdog 2024-01-22 16:24:04 +08:00
记得以前国内有个平台接入了微信 qq 第三方登录，某天腾讯把这个平台 ban 了，结果这个平台用户通过微信 qq 方式登录的就再也找不回原账号了。
此后，国内所有对接了第三方 oAuth 认证的统一要求绑定手机号/平台内账号防止出现类似情况。 登录是用户使用的第一步，把自己卵子交给 sass 这样的行为，对公司对用户都是不负责行为。 |
 |
42
utodea 2024-01-22 17:34:41 +08:00
技术上没什么难点，
|
 |
43
longbowape 2024-01-22 17:47:09 +08:00
@fkdog 手机号是法规实名认证的要求，和 oauth 没有关系
|
 |
44
Ayanokouji 2024-01-22 17:49:27 +08:00
|
 |
45
leo108 2024-01-22 18:15:01 +08:00
我面试高级研发候选人的时候最喜欢出的题目是设计一个通过邮箱实现重设密码模块的功能，能设计出没有明显缺陷的候选人估计也就 1/10 吧。
|
|
46
utodea 2024-01-22 20:37:39 +08:00
刚好我作为 Tech Lead 负责过某司的账号、支付中台性质的团队，这玩意技术上确实没什么难点！
出于个人兴趣我曾经读过 [ZITADEl]( https://github.com/zitadel/zitadel)大部分的代码,推荐给你 @annoygaga 。 确实 SASS 本身的设计会完备一些，但如果是自己实现即使业务到达了几百万 DAU ，亿级设备（之前我负责过的大概是这个量级） 我是觉得不存在什么技术难点，我在负责这个团队的时候遇到的难题都不是什么技术难题。实现一个基础的账户及登录系统、接一接各种登录方式，多则再自己搞个 OAuth2.0 Server ，这些都是业界非常成熟的方案了，能有啥技术难点。技术上，只要时刻提醒自己要关注账户安全性和登录服务高可用就行。 对于大部分使用开发者，接 auth0 和不接,前期估计能节省个一半的时间，也可能更多，特别是登录渠道多的时候。有些登录渠道的官方文档真不是人看的！接 auth0 可能你就没这些烦恼。产品早期 release 的速度很重要，开发者时间是成本核心。 等你的产品有不断的业务定制的时候，并且需要关注上面我说的账户安全性和登录服务高可用时。开始在 auth0 上各种堆💩，直到有一天觉得自建才能在上面三者平衡时。你开始考虑自有团队或者外包。直到外包或 SDK 代理商在定制性、安全性、高可用性无法满足时，你开始组建一个团队来负责。于是大概十个人左右的团队成为了公司的人力成本，我了解的几个中厂游戏公司都是这个规模（包含各种 SDK 的实现）。 @annoygaga #12 “想迁移就很难了”,是的。但是当公司走到了这一步的时候，大多数时候都是幸福的烦恼了（至少从公司层面是这样的）。 |
|
47
utodea 2024-01-22 20:49:14 +08:00
@Ayanokouji 绝大部分情况下我们需要的不是一个类似 Ory 这样的 SaaS 系统，只是需要一个提供基础账户、Auth 能力的系统。
极端点，没读过或者不理解 OAuth2 和 OIDC 的规范也能满足需求...... |
|
48
iseki 2024-01-22 20:51:39 +08:00 via Android
@annoygaga 正确实现 OAuth 2.0 ，你需要熟悉 IETF RFC 6749 6750 6819 ，这类平台一般还要实现 OIDC ，这部分规格不属于 IETF RFC ，但也有洋洋洒洒大几百页。这仅仅是开放互联的内容，尚未涉及到业务域，比如账号体系，授权认证体系等等。也不见得有多难，但是完全让你一个人做你可以估算估算自己要做多久。
|
|
49
iseki 2024-01-22 20:53:16 +08:00 via Android 1
@utodea 看你的需求是什么，如果你的需求是 OIDC 开放互联，你就只能去读这些文档了。规格文档只会说要什么，到底怎么落地得自己想。
|
 |
50
phrack 2024-01-22 20:53:29 +08:00 via iPhone
简单？我脑子看来确实不行，我感觉很复杂。
|
 |
51
holulu 2024-01-22 20:57:29 +08:00
每做一个应用都做一套 auth ，还得保证不出安全问题，成本就很高。有现成的为什么不接。例如做一个给开发者用的小应用，可能就一个页面，但要写个 auth ，就本末倒置了，直接接个 github auth ，用户用得方便，还不用管那么多安全问题。
|
|
52
matrix1010 2024-01-22 21:47:16 +08:00 1
@ck65 auth0 21 年初就被 okta 收购了。okta 是上市公司就没必要继续融资了
|
|
55
annoygaga OP @Ayanokouji 那假设已经有了 ory 这样的代码存在的情况下的难点呢？
|
 |
62
dayeye2006199 2024-01-23 02:25:26 +08:00 via Android
@ck65 auth0 直接被 okta 买了 65 亿美刀，彻底成功了，不用融资了
|
 |
63
qfdk 2024-01-23 04:28:43 +08:00
实现了一个 js 的 authserver 公司稳定运行 快三年了.
难点很多啊. 比如一开始我们是 spring 全家桶 自带的 oauth2.0 但是里面的版本有问题. 单位的人加了一层来处理权限.搞的乱七八糟. 搞的时候学了 ldap saml jwt 等等东西 oidc oauth2.0 的某些特殊规则. 这些都是看得到大点 还有跟多的细节. accesstoken 跟 idtoken 的区别啊 比如 callback URL 如何处理 如何连接多个 ldap ， 权限如何给 比如 token 分为给学生 老师 还是候选人 然后 每个 token 对应微服务的权限等等 |
 |
64
ilcn 2024-01-23 04:42:14 +08:00
这个帖子看出来楼主很矛盾。你问难点在哪，其他 v 友都已经回答了。回答了的你就继续问有没有资料，没回答的你就继续问有没有难点，没完没了的问为什么要付钱用其他人的服务。明明大家把所有的难点，风险，自己的开发维护审计合规成本都讲了，需要独立完成的协议架构也都讲了。你还要继续问难点。是看不懂中文吗？
|
 |
66
EINDEX 2024-01-23 13:52:31 +08:00
写文档，SLA ，运维不需要花钱吗？集成产品 1000 人就 $5000/m, 请一个团队开发就算你 5 个人，也要¥50000/m 。
关键你的公司早期不管是 2c 还是 2e 都不会有这么多人，有这么多钱为啥不做一些更业务相关的系统？ |
 |
67
Dogtler 2024-01-23 15:09:57 +08:00
同样类型的产品主要有 zitadel, logto ，keycloak ，我们公司之前也是做 saas 的，但是 oauth 实现都是自己搞得，除了一个 jwt 之外就感觉不正规了。复杂一些的还得权限之类的
|
|
68
Dogtler 2024-01-23 15:10:14 +08:00
goauthik
|
 |
69
czk1997 2024-01-23 17:14:05 +08:00
Okta 是面向 workforce 的其实我倒是能理解，企业的各种人员和系统管理很麻烦，还涉及的各个系统之间的通讯安全啥的。我们用的 Ping Identity, 从管理的角度来讲，比自己开发这种系统省心。目前市面上常见的几个系统，包括 keycloak, authentik 啥的，功能或多或少缺两个，要搞什么东西基本都得二次开发，比如 keycloak 缺 SCIM, goauthentik 缺 scope 管理，ory 没 ui 而且搭建起来异常复杂。
我不能接受的是面向 CIAM 的 auth0, 一些新技术不开放给免费用户，而且 auth0 的用户导出基本都说很麻烦，要找客服帮忙，典型的上云容易下云难了…… 再说用户资料本来就是企业机密…… |
|
70
keepRun 2024-01-23 23:42:21 +08:00
@javalaw2010 定制化很费劲 这个问题不是问题，因为选择这种服务的客户基本没有很多定制化需求，这个产品就是为了面向快速上线的。
其实对于选择这个服务的人，自己是需要想清楚该服务能否满足自己的需求。 从市场角度考虑，这种服务的火爆说明了快速搭建身份校验服务是有很大市场的。 |
Select Language