【面试集锦】如何设计SSO方案?和OAuth有什么区别?

如何设计SSO方案?和OAuth有什么区别?

--楼兰

带你聊最纯粹的Java

​ 如果面试问你,你会做一个权限系统吗?那你肯定会说做过。不就是各种登录、验证吗。我做的第一个CRUD应用就是注册、登录。简单!但是,如果问你在工作中真的做过权限系统吗?其实很多人都只能默默摇摇头。因为在很多真实项目中,权限系统可能不是最复杂的,但一定是牵连最广的。因此往往大型项目中真正去做权限系统的,都只是非常核心的一小部分人。而如果你的应用越来越复杂,作为安全门户的权限系统也会随着变得更加复杂。各种方案层出不穷。比如, 把SSO和OAuth这两个聊的最多的名词放到一起,你真的分清楚吗?


一、SSO与OAuth


​ 首先你要清楚, SSO和OAuth都是分布式场景下比较常见的权限认证方案。然后,这两个方案,在项目落地时,很多项目都会用SpringSecurity这一类的权限框架实现。所以,这两东西他们其实很像,但本质上,他们完全是两个不同的方案,解决不同的问题。

​ SSO是Single Sign-On,单点登录。主打的是统一。允许用户通过一次登录访问多个相互信任的系统,无需重复输入凭证。比如,你登录了淘宝后,访问天猫,自然也是登录的状态。而如果在淘宝退出登录后,访问天猫也同时退出登录了。

​ OAuth是Open Authorization,开放授权。主打的是开放。允许用户注册的一个账号,可以用来登录多个不同的平台。他们有很多本质的区别。比如,你可以用一个微信账号,登录很多网站。比如百度。

  • SSO关注的是统一登录。解决的是企业内部多系统之间的身份认证问题。OAuth关注的是开放授权。解决的是第三方应用如何安全获取用户资源的问题。
  • SSO强调状态共享,但是并不一定安全。所以通常SSO只是用在企业内部。比如淘宝和天猫。OAuth强调开放,同时也非常注重安全。可以在互联网共享同一套认证机制,同时保证保密信息不会泄露。比如你用微信登录百度,百度就只能拿到你的用户信息,
<think>我们正在讨论CAS协议与OAuth2.0在实现单点登录(SSO)上的本质区别。根据引用资料,我们可以总结如下:1.**目标定位不同**:-**CAS协议**:专注于解决单点登录(SSO)问题,是一个专门的身份认证协议。它仅处理用户身份的认证,确保用户一次登录即可访问多个应用系统[^4]。-**OAuth2.0**:本质上是一个授权框架,解决的是第三方应用在用户授权下访问资源服务器资源的问题。它并不直接处理用户身份认证,但可以通过扩展(如OpenIDConnect)来实现单点登录[^3]。2.**协议流程差异**:-**CAS流程**(基于票据):1.用户访问应用(Service,即CASClient)。2.应用重定向用户到CASServer进行认证。3.用户登录后,CASServer生成服务票据(ServiceTicket,ST)并重定向回应用。4.应用使用ST向CASServer验证,验证通过后建立本地会话[^4]。流程图如下:$$\text{用户}\rightarrow\text{应用}\rightarrow\text{CASServer}\rightarrow\text{验证ST}\rightarrow\text{建立会话}$$-**OAuth2.0流程**(基于令牌):1.用户访问客户端应用。2.客户端将用户重定向到授权服务器(AuthorizationServer)。3.用户授权后,授权服务器返回授权码(AuthorizationCode)给客户端。4.客户端使用授权码换取访问令牌(AccessToken)。5.客户端使用访问令牌访问资源服务器(ResourceServer)[^1]。流程图如下:$$\text{用户}\rightarrow\text{客户端}\rightarrow\text{授权服务器}\rightarrow\text{换取令牌}\rightarrow\text{访问资源}$$3.**安全模型区别**:-CAS的安全性依赖于HTTPS传输票据的一次性使用,确保ST不会被重复使用[^4]。-OAuth2.0通过访问令牌(AccessToken)刷新令牌(RefreshToken)机制,并支持多种授权方式(如授权码模式、隐式模式等)来适应不同场景的安全需求[^1][^3]。4.**适用场景**:-CAS适用于企业内部系统,尤其是需要统一认证且不涉及第三方授权的场景[^4]。-OAuth2.0更适用于开放平台或需要第三方应用接入的场景(如使用微信、QQ登录其他网站)[^2][^3]。5.**扩展性**:-CAS协议本身较为简单,扩展能力有限。-OAuth2.0具有较好的扩展性,例如通过OpenIDConnect(OIDC)在OAuth2.0基础上添加了身份认证层,从而支持SSO[^3]。###核心差异总结表|**维度**|**CAS协议**|**OAuth2.0**||----------------|-----------------------------|-----------------------------||**核心目标**|解决单点登录(认证)|解决资源授权(授权)||**令牌类型**|服务票据(ST)|访问令牌(AccessToken)||**流程复杂度**|简单直接|相对复杂(支持多种授权模式)||**适用场景**|企业内部系统|开放平台/第三方授权||**扩展能力**|有限|强(如通过OIDC支持认证)|###实现原理代码对比####CAS客户端验证ST的伪代码```java//CASClient验证STpublicbooleanvalidateServiceTicket(StringserviceTicket){StringcasUrl="https://cas-server/validate?ticket="+serviceTicket+"&service="+service;HttpResponseresponse=httpClient.get(casUrl);returnresponse.getBody().contains("yes");//CAS协议返回"yes\nusername"}```####OAuth2.0授权码模式获取令牌的伪代码```java//OAuth2.0使用授权码换取令牌publicTokenResponseexchangeCodeForToken(Stringcode){OAuth2Clientclient=newOAuth2Client(clientId,clientSecret);TokenRequestrequest=newTokenRequest(grantType="authorization_code",code,redirectUri);returnclient.execute(request);//返回访问令牌刷新令牌}```###结论-如果需求是**封闭系统的统一登录认证**,选择**CAS**更简单直接。-如果需求涉及**开放平台或第三方授权**,则**OAuth2.0(特别是OIDC)**是更合适的选择[^2][^3]。§§相关问题§§1.如何将CAS协议与OAuth2.0结合使用以满足复杂场景?2.OpenIDConnect(OIDC)在OAuth2.0基础上添加了哪些认证特性?3.CAS协议中服务票据(ST)的安全性如何保证?4.在微服务架构中,如何选择CAS或OAuth2.0实现SSO?</think>### CAS协议 vs OAuth2.0 在 SSO 实现中的核心差异 #### 1. 本质定位差异 | 维度 | CAS协议 | OAuth2.0 | |--------------|----------------------------------|------------------------------| | **核心目标** | 专注**身份认证** | 专注**授权委托** | | **协议性质** | 专用认证协议 | 通用授权框架 | | **主要场景** | 企业内部系统统一登录 | 第三方应用资源访问授权 | | **标准化** | 轻量级专有协议 | IETF标准协议(RFC 6749) | #### 2. 技术实现原理对比 **CAS协议流程** (基于票据交换): ```mermaid sequenceDiagram participant 用户 participant 应用A participant CAS服务器 用户->>应用A: 访问受保护资源 应用A->>用户: 重定向到CAS登录页 用户->>CAS服务器: 提交凭证 CAS服务器->>用户: 颁发服务票据(ST) 用户->>应用A: 携带ST访问 应用A->>CAS服务器: 验证ST有效性 CAS服务器->>应用A: 返回认证结果 应用A->>用户: 授予访问权限 ``` **OAuth2.0流程** (基于令牌授权): ```mermaid sequenceDiagram participant 用户 participant 客户端应用 participant 授权服务器 participant 资源服务器 用户->>客户端应用: 发起访问请求 客户端应用->>用户: 重定向到授权服务器 用户->>授权服务器: 登录并授权 授权服务器->>用户: 返回授权码 用户->>客户端应用: 携带授权码 客户端应用->>授权服务器: 用授权码换令牌 授权服务器->>客户端应用: 颁发访问令牌 客户端应用->>资源服务器: 用令牌访问资源 资源服务器->>客户端应用: 返回受保护数据 ``` #### 3. 核心组件差异 | **组件** | **CAS协议** | **OAuth2.0** | |----------------|-----------------------------|----------------------------| | 身份凭证 | 服务票据(ST) | 访问令牌(Access Token) | | 验证机制 | 服务端票据校验 | 令牌签名验证(JWT) | | 会话管理 | 中央会话存储 | 无状态令牌 | | 典型传输方式 | HTTP重定向 | API调用 | #### 4. 关键区别详解 1. **信任模型** - CAS:建立**中心化信任**,所有应用信任CAS服务器 $$ \text{Trust} = \text{App}_1 \oplus \text{App}_2 \oplus \cdots \oplus \text{CAS} $$ - OAuth2.0:实现**分布式信任**,资源服务器独立验证令牌 $$ \text{Trust} = \text{RS}_1 \otimes \text{RS}_2 \otimes \cdots \otimes \text{AS} $$ 2. **安全边界** - CAS适用于**封闭系统**(企业内网) - OAuth2.0设计用于**开放系统**(互联网应用) 3. **协议扩展性** - CAS需定制扩展新功能(如MFA) - OAuth2.0天然支持OpenID Connect实现认证 4. **令牌生命周期** ```java // CAS服务票据(短时效) ServiceTicket st = new ServiceTicket(user, 30); // 30秒有效期 // OAuth2访问令牌(长时效) AccessToken token = new AccessToken(user, 3600); // 1小时有效期 ``` #### 5. 适用场景建议 - **选择CAS当**: ✅ 企业内网系统整合 ✅ 需要严格会话控制 ✅ 简单认证需求 - **选择OAuth2.0当**: ✅ 第三方应用集成 ✅ 移动/API优先架构 ✅ 需要细粒度授权 #### 6. 混合架构示例 ```java // CAS-OAuth2混合认证控制器 @RestController public class AuthController { @GetMapping("/sso/login") public ResponseEntity<Object> ssoLogin( @RequestParam String service, HttpServletRequest req) { // CAS风格认证 if (isInternalService(service)) { String st = casService.generateTicket(req.getRemoteUser()); return ResponseEntity.ok(Collections.singletonMap("ticket", st)); } // OAuth2风格认证 else { String authCode = oauthService.issueAuthorizationCode(req.getRemoteUser()); return ResponseEntity.status(302) .header("Location", service + "?code=" + authCode) .build(); } } private boolean isInternalService(String url) { return url.contains(".internal.com"); } } ``` ### 总结对比矩阵 | **特性** | **CAS** | **OAuth2.0** | **最优场景** | |------------------|---------------|-----------------|---------------------| | 协议复杂度 | ★★☆ | ★★★★ | 简单认证 vs 复杂授权 | | 跨域支持 | 有限 | 原生支持 | 互联网应用 | | 移动端适配 | 困难 | 优秀 | 移动应用 | | 标准化程度 | 专有 | RFC标准 | 开放生态系统 | | 实施成本 | 低 | 中高 | 企业内网 vs SaaS | > 关键结论:CAS是"垂直型"认证方案OAuth2是"水平型"授权框架。现代SSO常采用**OAuth2.0+OpenID Connect**组合方案[^3],因其兼具认证能力标准化优势[^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

roykingw

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值