Protected App:（几乎）无需代码给任意 web app 添加 authentication

[logto]

大家好！ Protected App 是一个基于我们的开源项目 Logto 的新功能。只需填写两个字段，便可以给任意的 web app 添加一层 authentication：

1. 假设你的 web app 位于 https://foo.app/
2. 在 Logto Cloud 中，新建一个 Protected App:
   • Origin URL 填写 https://foo.app/
   • App domain 填写 foo
3. 创建完成后，匿名访问 https://foo.protected.app/ 即会自动跳转到登录页
4. 最后不要忘记在 https://foo.app/ 中验证发过来的 token （这部分需要写一点点简单的验证逻辑）

Protect App 的优势

• 速度极快：Protected App 部署在 Cloudflare Worker 上，自带全球 CDN
• 安全性高：每一个 Protected App 底层都是一个正规的 OIDC client ，整个认证过程和 Logto 其他类型的 app 一致
• 框架无关：适用于任何 web 框架，无需侵入代码。配合 API Gateway 等网关产品，可以做到业务和认证完全分离
• 扩展性强：Protected App 作为 Logto 的一部分，你可以体验到 Logto 的所有功能：SSO （单点登录），RBAC （基于角色的访问控制），MFA （多重因素验证），和 Organizations （多租户） 等等

欢迎体验，也希望听到大家的建议 😊

---

• 有关 Protected App 的更多介绍： https://logto.io/products/protected-app
• 背后的故事和实现原理： https://blog.logto.io/protected-app

[logto]

@doveyoung 谢谢，Protected App 可以绑定自己的域名，不一定是 foo.protected.app 哈

[wuyuandev]

@logto #11 《支持》

[moving80kg]

同 @xiaohanyu , 我们一开始也是自己写了 auth 。一开始是给一家公司做了一个内部使用的系统，后面这个公司把这套系统推给了一些上下游的合作方，做成 SaaS 来卖，顺便集成一些上下游的服务。

结果发现 auth 是个大问题。不同群体的用户有不同的需求，有的要邮件，有的要手机号，还有的要求要多因素认证（输入动态码啥的）。一开始在自己的 auth 上扩展，后面发现越做越复杂，也越做越乱，感觉 auth 没有想象中的那么简单，后面还涉及到角色权限管理、资源访问的限制什么的，人手有限，无脑做下去感觉就是火葬场。

中途调研了 keycloak 、auth0 、clerk 、logto 等一堆，最后发现 logto 提供的功能能完全满足我们的需求，用 logto cloud 简单快速接入了一下，感觉很满意，各种需求也能满足，就自己部署了开源版本了（国内访问不行，开源版和付费版本的功能竟然一样），接入 logto 后，auth 这块在未来一段时间里面就不用管了。

[moving80kg]

不同意 @nicoljiang 的看法，感觉这位老哥有点暴躁，碰巧我也有点暴躁。

他说：觉得因为想解决一个小问题引入了一套复杂的东西实在得不偿失。在集成了之后修了几个小 bug ，发现不太搞得定，然后说发现了这套东西“实际”“真的”“很简单”。

这里的问题主要在于集成之前没有做调研，没有弄清楚自己的需求，一上来就干，干不对就喷，喷起来就是这套东西“实际”“真的”“很简单”。

明明是要解决一个小的需求，接入了 casdoor 不行，并且感觉很不满，然后又接入一次 logto ，最后发现原来自己的需求很简单，用不到这些服务，然后张口就来说这些东西很简单（其实自己自己的需求简单），“被一个个名词和协议吓到了”（其实是自己集成前都没有做调研），然后就要开始用非常普及的 Rust 来自己撸一套（简单的）了，真的是有钱（不怕花成本）又暴躁。人家 Casdoor 做开源也没收你的钱，Logto 虽然有付费版本，但一看你修了 bug 也是用的开源版，也没收你的钱，还要受你的委屈，真的冤枉。

在没有搞清楚自己的需求，也没有调研清楚技术选型是否能解决自己的需求时就开始着手接入，肯定会遇到各种问题，但是这问题主要还是出在自己身上。

[nicoljiang]

@moving80kg
1. 我没用 logto
2. 所以 8 楼和 9 楼分享了自己的判断，帮助其他人更明确需求
3. 并且受 10 楼邀请在 17 楼做了一些说明和补充
4. 然后因 18 楼的误解在 20 楼又做了说明和补充
5. 最后因 24 楼的莫名奇妙在 25 楼做了一次梳理

请问有什么问题吗？

[nicoljiang]

@moving80kg
另外 casdoor 项目用起来小问题，这也很大程度打击我们的使用信心。这个跟需求是无关的。
原本我以为是我们的错觉，但看到 https://www.v2ex.com/t/1021725 发现同样有人提到（缺乏测试）。

再提一次之前说过的声明，如果他们出了 SAAS 服务，我觉得可以一用，因为有服务，小问题只要甩给他们就可以解决。自部署开源版本，建议慎用。

[xiaohanyu]

@moving80kg 对的，我跟你的历程几乎是一样的，我去年开始做自己的 SaaS ，最开始也是自己写 auth （而且我之前有几次集成 OAuth 的经验），后来发现要把 auth 写好（好用 + 健壮 + 安全），不是一件容易的事。我之前也集成过 auth0 ，不过 auth0 一来是费用贵，二是对国内的访问速度也蛮慢的，所以后来调研别的解决方案，发现了 logto ，还是蛮好用的。

我自己写 auth 过程中最大的痛点还是 account linking ，就是多种登录方式在系统中链接到同一个 account 的问题，很多商业产品其实这一点做的也是不够好的，很容易让人困惑，logto 比较好的解决了这个问题。

接入专业的 auth solution 后确实这块不用怎么管了，毕竟我是做我自己的 SaaS ，不是做 auth 的哈哈。