为什么很多 OpenID 框架都要把登录和权限管理分成两个服务？例如天天在 V 站置顶烦人的广告的那个，也是把登录和权限管理拆成两个项目。这两个总是同时存在的，做在一起不好吗？

登录和权限对应的是英文的 Authentication 和 Authorization ，是两个相似但不同的东西。
登录解决的是你是谁
授权解决的是你能干什么

你一个 QQ 号能登录多少服务，你在这些服务里的权限都是一样的吗？
QQ 音乐只关心绿钻，也不关心黄钻吧。

@kaneg #1 我知道这两个是不同的，但是这解释不了为什么总要把这两个拆成两个服务，做成同一个账号（ Account ）服务不是部署和维护更方便吗？如果 Authentication 服务挂了 Authorization 也就没有意义了，相反也是。

@learningman 2 楼的解释差不多理解了，Authorization 是每个服务都有一个，Authentication 是整个用同一账号的系统只有一个，修改密码、绑定第三方账号等都由 Authentication 管，哪些用户能访问后台、订阅会员 Only 的资源由 Authorization 管么

@edis0n0 你不要将这个身份服务器当作只有你们内部使用的，而是一个公用可被第三方接入的，你一下就明白了，并不是所有的身份服务都需要权限模块，而且这 2 个东西在做服务切分的时候，从概念上就是天然分离的。另外很多时候就如同你说的，将服务分开后，的确会带来部署开销，更严重的是一致性和分布式通讯问题，但为了整个系统的规模扩展有时候不得不付出这种代价。身份(Identity)/身份信息(Claims), 同授权并没有那个严格的关联，授权也完全可用不依赖于身份，只是大部分时候，基于用户身份的授权最常用，让我们将其紧密关联在了一起。

理想 良好的设计 现实 做在一起也没问题
我这边就是做在一起

如果你理解不了，说明你还没用到，那么你现在可以当成 1 个来看，但是别真的当成 1 个用
等你觉得 authentication 和 authorization 不一样的时候，自然就明白了

因为登录和授权本身就是两个事情，只是在一些简单的场景下被合在一起使用了，但是需要清楚它们本身是不同的

先明确一个概念：Authentication 和 Authorization 是两个不同的职责，互相没有强依赖关系，只是在常见的业务场景上会组合在一起使用，这两者是各自独立存在的。

打个比方：用户和订单在常见的业务上会组合在一起使用，但他们没有强依赖关系，是各自独立存在的。那把用户和订单放到一个项目里好吗？显然是不合适的。

“这两个总是同时存在的，做在一起不好吗？”
这个问题的本质是如何确定服务的职责边界？如果处理不好，就会往单体架构发展，优缺点就很明显了。

认证是大家都有的，授权是业务强相关的，即使大家都用统一模型例如 rbac 这种，但是数据权限也无法统一解决

授权也不一定需要登录，比如匿名授权也是一种授权，登录这种场景就是匿名授权的。

AuthN 和 AuthZ 天然就是两码事

认证和权限管理分开的话，各个接入系统就可以单独处理权限的业务。
举个例子:
我司有个协同平台，里面可以跳转多个其他的服务，我们是通过 cas 认证实现，携带一个类似 token 的东西给其他服务，其他服务通过这个 token 可以请求 cas 获取认证的用户名称，然后走正常的登录校验就可以了（其实跟账号密码登录一样，但是只给了一个来自 cas 的用户名）。
内部服务如果外部人员需要使用，可以在其他服务添加用户（这个用户不存在于协同平台），外部人员就可以走账号密码登录获取权限。

有个比较头疼的问题就是协同平台的用户库和服务平台的用户库需要定时同步

OP 你理解的没错，大部分项目是为了拆而拆。

@yuanxin1999 为啥需要同步用户呢？用户的 identity 不应该只由一个单一服务持有吗？

@thinkershare 因为每个服务的外部用户可能不一样，我其实也不太理解つ