为什么很多 OpenID 框架都要把登录和权限管理分成两个服务？例如天天在 V 站置顶烦人的广告的那个，也是把登录和权限管理拆成两个项目。这两个总是同时存在的，做在一起不好吗？
edis0n0 · 2023-01-17 21:31:20 +08:00 · 2349 次点击这是一个创建于 671 天前的主题，其中的信息可能已经有所发展或是发生改变。
传统企业，只会最简单 CRUD 的程序员真的不理解。
 |
1
kaneg 2023-01-17 21:46:40 +08:00
登录和权限对应的是英文的 Authentication 和 Authorization ，是两个相似但不同的东西。
登录解决的是你是谁 授权解决的是你能干什么 |
 |
2
learningman 2023-01-17 21:48:36 +08:00  1
你一个 QQ 号能登录多少服务，你在这些服务里的权限都是一样的吗？
QQ 音乐只关心绿钻，也不关心黄钻吧。 |
 |
3
edis0n0 OP @kaneg #1 我知道这两个是不同的，但是这解释不了为什么总要把这两个拆成两个服务，做成同一个账号（ Account ）服务不是部署和维护更方便吗？如果 Authentication 服务挂了 Authorization 也就没有意义了，相反也是。
|
|
4
edis0n0 OP @learningman 2 楼的解释差不多理解了，Authorization 是每个服务都有一个，Authentication 是整个用同一账号的系统只有一个，修改密码、绑定第三方账号等都由 Authentication 管，哪些用户能访问后台、订阅会员 Only 的资源由 Authorization 管么
|
 |
5
thinkershare 2023-01-17 22:06:59 +08:00
@edis0n0 你不要将这个身份服务器当作只有你们内部使用的，而是一个公用可被第三方接入的，你一下就明白了，并不是所有的身份服务都需要权限模块，而且这 2 个东西在做服务切分的时候，从概念上就是天然分离的。另外很多时候就如同你说的，将服务分开后，的确会带来部署开销，更严重的是一致性和分布式通讯问题，但为了整个系统的规模扩展有时候不得不付出这种代价。身份(Identity)/身份信息(Claims), 同授权并没有那个严格的关联，授权也完全可用不依赖于身份，只是大部分时候，基于用户身份的授权最常用，让我们将其紧密关联在了一起。
|
 |
6
urnoob 2023-01-17 22:42:35 +08:00 via Android
理想 良好的设计 现实 做在一起也没问题
我这边就是做在一起 |
 |
7
pming1 2023-01-18 09:13:41 +08:00
取决于业务复杂性和系统规模，脱离具体业务场景来谈架构设计好与坏是无意义的。大原则是，业务越复杂，系统模块就会拆得越细，从而更灵活，当然也换来更高的研发和维护成本。
|
 |
8
doveyoung 2023-01-18 09:19:10 +08:00
如果你理解不了，说明你还没用到，那么你现在可以当成 1 个来看，但是别真的当成 1 个用
等你觉得 authentication 和 authorization 不一样的时候，自然就明白了 |
 |
9
NeroKamin 2023-01-18 10:25:39 +08:00
因为登录和授权本身就是两个事情，只是在一些简单的场景下被合在一起使用了，但是需要清楚它们本身是不同的
|
 |
10
justplaymore 2023-01-18 10:32:20 +08:00
先明确一个概念：Authentication 和 Authorization 是两个不同的职责，互相没有强依赖关系，只是在常见的业务场景上会组合在一起使用，这两者是各自独立存在的。
打个比方：用户和订单在常见的业务上会组合在一起使用，但他们没有强依赖关系，是各自独立存在的。那把用户和订单放到一个项目里好吗？显然是不合适的。 “这两个总是同时存在的，做在一起不好吗？” ——这个问题的本质是如何确定服务的职责边界？如果处理不好，就会往单体架构发展，优缺点就很明显了。 |
 |
11
litchinn 2023-01-18 11:08:00 +08:00
认证是大家都有的，授权是业务强相关的，即使大家都用统一模型例如 rbac 这种，但是数据权限也无法统一解决
|
 |
12
wdlth 2023-01-18 13:02:41 +08:00
授权也不一定需要登录，比如匿名授权也是一种授权，登录这种场景就是匿名授权的。
|
 |
13
lologame 2023-01-18 15:20:38 +08:00
AuthN 和 AuthZ 天然就是两码事
|
|
14
lologame 2023-01-18 15:22:19 +08:00
|
 |
15
yuanxin1999 2023-01-18 16:05:50 +08:00
认证和权限管理分开的话，各个接入系统就可以单独处理权限的业务。
举个例子: 我司有个协同平台，里面可以跳转多个其他的服务，我们是通过 cas 认证实现，携带一个类似 token 的东西给其他服务，其他服务通过这个 token 可以请求 cas 获取认证的用户名称，然后走正常的登录校验就可以了（其实跟账号密码登录一样，但是只给了一个来自 cas 的用户名）。 内部服务如果外部人员需要使用，可以在其他服务添加用户（这个用户不存在于协同平台），外部人员就可以走账号密码登录获取权限。 有个比较头疼的问题就是协同平台的用户库和服务平台的用户库需要定时同步 |
 |
16
MrSheng 2023-01-18 17:27:49 +08:00
OP 你理解的没错，大部分项目是为了拆而拆。
|
|
17
thinkershare 2023-01-18 17:34:44 +08:00
@yuanxin1999 为啥需要同步用户呢？用户的 identity 不应该只由一个单一服务持有吗？
|
|
18
yuanxin1999 2023-01-19 08:20:20 +08:00
@thinkershare 因为每个服务的外部用户可能不一样，我其实也不太理解つ﹏⊂
|
Select Language