# 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