目录

开源认证基础服务

0x00 前言

随着业务的增长,往往需要统一体系内的服务的账户。

经过一番调研,决定尝试一下 ory 的开源认证基础服务

0x01 ORY 尝试解决问题?

ORY 提供了四个主要项目,每个项目着力于解决一个边界清晰的认证 / 鉴权问题

  • ORY Kratos 提供了用户认证服务
  • ORY Hydra 提供了 OAuth 2.0 & OpenID Connect provider.
  • ORY Keto 提供了 访问控制
  • ORY Oathkeeper 提供了认证访问代理

0x02 用户认证服务 Kratos

常见方案

  1. 方案 1, 选择全栈式解决方案 - 比如 Java 社区的 JGroups
  2. 方案 2, 选择 IDaas - 比如 Login With Apple, Google
  3. 方案 3, 选择自己来 - 比如 Java 社区的 JGroups

三种方案各有利弊

  1. 全栈式解决方案上手极快,但
    • 扩展性不强
    • 绑定 Java 技术栈
    • 数据模型固定
    • 登陆流程固定
  • 更新迭代慢
  1. Login With Google 虽然方便,但是并没有解决如下的问题
  • 更新 Profile
    • 添加第二个恢复邮箱
    • 2FA
    • 存储管理 Sessions
  • 全局登出
  1. 自己来,需要处理事情也挺多
  • 方案二遇到的问题,一个不会少
  • 加密算法
    • 流程可能较为复杂,比如先用邮箱注册,然后用 Sign Up Using Google, 或者先用 Sign Up Google, 然后使用邮箱登陆。(PS: 我国的登陆姿势就更多了)

是不是某种方案是最好的呢?其实未必

就我个人经验来说,

  • 第一种方案比较适合稳定的,技术栈相同的团队使用。如果对原先应用进行少量裁剪就可以使用,其实未尝不可。
  • 第二种方案如果登陆入口仅是 Login With Google, 并且内网服务数量就几个,也不需要做全局登出,那么其实做起来比较省事。我工作过的一个公司就喜欢这么干。
  • 第三种方案虽然处理的问题看起来比较多,但是社区现有的 Building Block 已经比较多了。如果流程没有特别复杂,一手打造的非常容易往自己的项目发展情况发展。

Kratos 的方案

Kratos 提供了如下的解决方案

  • 登陆与注册
  • track sesison/devices
  • MFA/2FA
  • 账户验证
  • 账户恢复
  • Profile & Account Management
  • 管理后台接口 API
  • 消费 OAuth2 and OpenID Connect

0x03 Ory Hydra

You May Not Need It

0x03 Ory Keto

权限系统一般放在按照产品需求,最好跟着产品走。而不是随随便便提取出来做一个权限系统。

You May Not Need It

0x04 Ory Oathkeeper

同样,如果你不是有做 zero trust

You May Not Need It