Protected App:（几乎）无需代码给任意 web app 添加 authentication
logto · logto-io · 196 天前 · 2461 次点击这是一个创建于 196 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家好！ Protected App 是一个基于我们的开源项目 Logto 的新功能。只需填写两个字段，便可以给任意的 web app 添加一层 authentication：
- 假设你的 web app 位于
https://foo.app/ -
在 Logto Cloud 中，新建一个 Protected App:
- Origin URL 填写
https://foo.app/ - App domain 填写 foo
- Origin URL 填写
- 创建完成后，匿名访问
https://foo.protected.app/即会自动跳转到登录页 - 最后不要忘记在
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
27 条回复 • 2024-05-12 19:41:11 +08:00
 |
1
lekai63 196 天前  1
关注 logto 很久了。。然而一直没着手集成到 app 里去~
|
 |
2
Chad0000 196 天前 via iPhone
不就是 oauth2 么
|
 |
3
yuezk 196 天前 2
听起来像是在 LB 层做了 authentication ，token 通过 HTTP header 传给后面的服务，叫法不一，我们内部叫 trusted authentication 。老牌的 IDP 像 Pingfederate 和 SiteMinder 好像都支持类似的功能，不过可能没有楼主的易用。
|
 |
4
grimbedroom 196 天前
提一嘴，开着 vpn 用谷歌登录，登录了四遍才进去
|
 |
5
logto OP @grimbedroom vpn 是哪里的节点，出了什么问题呢？我们目前服务器在欧洲，可能会有一些延迟
|
|
6
grimbedroom 196 天前
@logto 韩国春川，谷歌选择账号后回调到你们的网页，加载了一会就不加载了，重试了三次进入注册流程了，现在退出重新登录没复现了
|
|
7
logto OP @grimbedroom 感谢，我们去尝试复现一下
|
 |
8
wuyuandev 196 天前
尝试自托管 logto 以后坚定了自己写登录功能的决心
|
 |
9
nicoljiang 196 天前
@wuyuandev 用了 casdoor 之后也坚定了自己写的决心。
|
 |
10
cydian 196 天前
@nicoljiang 老哥讲讲 casdoor 正准备新项目接入一下试试
|
 |
13
0o0O0o0O0o 196 天前 1
看介绍很喜欢，蹲一下开源
|
 |
14
kidlj 196 天前 1
很喜欢 Logto ，也尝试集成过，希望开源版能支持多租户，不然国内企业很难用起来（服务器在欧洲）。
|
 |
15
xiaohanyu 196 天前 2
跟楼上 @wuyuandev 和 @nicoljiang 相反，我是自己先写了 auth ，之后又花时间全部迁移到了 logto ，也是自托管，用了快小半年了，还是非常非常推荐了。
当然，自托管确实还是有一些部署和运维上的复杂性，SRE 方面比较弱的小伙伴们，还是推荐用下 logto cloud ，蛮好的。 写的两篇迁移到 logto 的文章： - [Introducing the New Auth Flow for PPResume]( https://blog.ppresume.com/posts/introducting-the-new-auth-flow?utm_source=v2ex&utm_medium=xiaohanyu&utm_campaign=logto-protected-app) - [Introducing Google Sign In for PPResume]( https://blog.ppresume.com/posts/introducing-google-sign-in?utm_source=v2ex&utm_medium=xiaohanyu&utm_campaign=logto-protected-app) 仅供参考哈 --- Protected app 的 idea 蛮好的，个人感觉依照 express middleware 的方式，通过一个 proxy 来抽离出 auth layer ，very smart 。就我个人体验而言，接入 logto 作为一个第三方的 auth server ，因为要同时在前端和后端都验证 auth token ，所以要接入两套 SDK ，还是有些复杂度的。 不过目前看上去 protected app 功能可能还是比较有限，跟 SDK 的接入还是无法对标的。看场景啦。 |
|
16
logto OP @xiaohanyu 谢谢你的支持，Protected App 目前更适合快速接入，功能丰富度上暂时比不过 SDK 。好在 Protected App 底层也是 OIDC client ，后期如果有高级需求可以无缝迁移到 SDK 集成。
|
|
17
nicoljiang 196 天前
@cydian 本身希望非常简单地接入使用，结果还是遇到很多磕磕绊绊。实际使用之后发现整体比较复杂，比较难在短时间搞熟。另外也不排除有一些小问题小 bug ，我们自己还修改了代码，这个时候已经有了一些不满（原本就是为了自己可以不亲自处理这方面的东西），但由于使用场景目前也非常简单，自己修了 2 个 bug 后倒也相安无事，就继续用。
后在使用其他服务需要用到一键登录的需求时，发现又不能直接使用（结果还得自己写了个中转接口）。最后痛定思痛，觉得因为想解决一个小问题引入了一套复杂的东西实在得不偿失，而且连最初的目的都达不到（成为账户中心，方便接入）。 @xiaohanyu 我们也是在自己修了几个小 bug 之后其实也是真切体会到，这套东西实际真的很简单，但之前被一个个的名词和一套套的协议给吓到了。本质就是一个特别简单的东西，不值得引入复杂的不确定性因素。当然使用云服务，有专业支持的话，问题可能不大。现在自己写了，接入什么都很容易实现，灵活度和可靠性大大提高。 |
 |
18
pseudo 195 天前 via iPhone
@nicoljiang 我理解你遇到的问题是和 casdoor 相关的哈，和本帖无关。
此外，通过自己的场景推断某一个事物“简单”未免有些草率了。同样的逻辑可以推断出 Redis 也真的很简单，只是 KV 存储；前端也真的很简单，只是 DOM 操作； Machine learning 也真的很简单，只是给机器喂数据。 |
 |
19
doveyoung 195 天前 1
最开始我的用法是 foo.app 在 nginx 做 auth 验证拦截，引入 vouch 让 nginx 拥有可以和 OIDC 对接的能力，logto 作为 provider 。
后来发现 logto cloud 有了 protected 还想试试，但是要再去访问 foo.protected.app ，有些时候不想访问别人的域名，而且也不支持 oss 版本，现在已经没这个念想了 emmm 不过 logto 真是一个很好用的项目 |
|
20
nicoljiang 195 天前
@pseudo 我没说 Logto 和 Casdoor 简单，反而是说：我们的需求很简单，他们太复杂（然后又容易引入一些小问题）所以才决定自己写。
所以这些只和 casdoor 有关吗？ logto 是不是已经做得非常健壮、安全、完整了？是否可以支持上有自定义需求的一键登录行为了，我不知道，你知道吗？ 现在 rust 都这么普及了，我们自己早就用自研的东西把 Nginx 系、dnsmasq 系这种简单的组件替代掉了，再替换掉 Redis 这种简单的工具替代掉有什么奇怪的吗？ 其他的，你就别跟我扯什么耶稣上帝了，跟我没关系，跟你也没关系（你这杠真的有必要抬到把 Redis 一个简单的工具跟整个前端、机器学习这种大生态的行业强行做对比吗？）。 |
|
21
logto OP @doveyoung 谢谢，Protected App 可以绑定自己的域名，不一定是 foo.protected.app 哈
|
 |
23
moving80kg 193 天前
同 @xiaohanyu , 我们一开始也是自己写了 auth 。一开始是给一家公司做了一个内部使用的系统，后面这个公司把这套系统推给了一些上下游的合作方，做成 SaaS 来卖，顺便集成一些上下游的服务。
结果发现 auth 是个大问题。不同群体的用户有不同的需求，有的要邮件，有的要手机号，还有的要求要多因素认证（输入动态码啥的）。一开始在自己的 auth 上扩展，后面发现越做越复杂，也越做越乱，感觉 auth 没有想象中的那么简单，后面还涉及到角色权限管理、资源访问的限制什么的，人手有限，无脑做下去感觉就是火葬场。 中途调研了 keycloak 、auth0 、clerk 、logto 等一堆，最后发现 logto 提供的功能能完全满足我们的需求，用 logto cloud 简单快速接入了一下，感觉很满意，各种需求也能满足，就自己部署了开源版本了（国内访问不行，开源版和付费版本的功能竟然一样），接入 logto 后，auth 这块在未来一段时间里面就不用管了。 |
|
24
moving80kg 193 天前
不同意 @nicoljiang 的看法，感觉这位老哥有点暴躁，碰巧我也有点暴躁。
他说：觉得因为想解决一个小问题引入了一套复杂的东西实在得不偿失。在集成了之后修了几个小 bug ，发现不太搞得定，然后说发现了这套东西“实际”“真的”“很简单”。 这里的问题主要在于集成之前没有做调研，没有弄清楚自己的需求，一上来就干，干不对就喷，喷起来就是这套东西“实际”“真的”“很简单”。 明明是要解决一个小的需求，接入了 casdoor 不行，并且感觉很不满，然后又接入一次 logto ，最后发现原来自己的需求很简单，用不到这些服务，然后张口就来说这些东西很简单（其实自己自己的需求简单），“被一个个名词和协议吓到了”（其实是自己集成前都没有做调研），然后就要开始用非常普及的 Rust 来自己撸一套（简单的）了，真的是有钱（不怕花成本）又暴躁。人家 Casdoor 做开源也没收你的钱，Logto 虽然有付费版本，但一看你修了 bug 也是用的开源版，也没收你的钱，还要受你的委屈，真的冤枉。 在没有搞清楚自己的需求，也没有调研清楚技术选型是否能解决自己的需求时就开始着手接入，肯定会遇到各种问题，但是这问题主要还是出在自己身上。 |
|
25
nicoljiang 193 天前
@moving80kg
1. 我没用 logto 2. 所以 8 楼和 9 楼分享了自己的判断，帮助其他人更明确需求 3. 并且受 10 楼邀请在 17 楼做了一些说明和补充 4. 然后因 18 楼的误解在 20 楼又做了说明和补充 5. 最后因 24 楼的莫名奇妙在 25 楼做了一次梳理 请问有什么问题吗？ |
|
26
nicoljiang 193 天前
@moving80kg
另外 casdoor 项目用起来小问题，这也很大程度打击我们的使用信心。这个跟需求是无关的。 原本我以为是我们的错觉，但看到 https://www.v2ex.com/t/1021725 发现同样有人提到（缺乏测试）。 再提一次之前说过的声明，如果他们出了 SAAS 服务，我觉得可以一用，因为有服务，小问题只要甩给他们就可以解决。自部署开源版本，建议慎用。 |
|
27
xiaohanyu 193 天前
@moving80kg 对的，我跟你的历程几乎是一样的，我去年开始做自己的 SaaS ，最开始也是自己写 auth （而且我之前有几次集成 OAuth 的经验），后来发现要把 auth 写好（好用 + 健壮 + 安全），不是一件容易的事。我之前也集成过 auth0 ，不过 auth0 一来是费用贵，二是对国内的访问速度也蛮慢的，所以后来调研别的解决方案，发现了 logto ，还是蛮好用的。
我自己写 auth 过程中最大的痛点还是 account linking ，就是多种登录方式在系统中链接到同一个 account 的问题，很多商业产品其实这一点做的也是不够好的，很容易让人困惑，logto 比较好的解决了这个问题。 接入专业的 auth solution 后确实这块不用怎么管了，毕竟我是做我自己的 SaaS ，不是做 auth 的哈哈。 |
Select Language