企鹅极客｜医药AI大数据及众应用场景用户身份认证技术选择技巧之OAuth2 or CAS

随着AI、大数据、各种应用技术以及各种软硬件

多端设备底层技术的蓬勃发展，医药企业面临用户使用多系统、多数据来源、多端访问等用户登陆的体验问题。本文主要陈述了未名企鹅如何选择身份认证技术，以应对用户在自身AI、大数据及应用系统和周边生态系统的灵活转换身份关系、访问权限，并保障数据安全的几点思考。重点讲述了Oath2和CAS之间的区别以及场景选择建议。

在现代应用中，身份认证（Authentication） 是确保用户身份真实可靠的关键步骤。它用于验证用户是否是其声称的身份，并允许其访问受限资源。常见的身份认证方式包括：

• 账号密码登录：最基础的认证方式，但存在密码泄露风险。

• 短信验证码：通过手机短信发送验证码进行认证，增强安全性，但有拦截和滥用风险。

• OAuth2：一种授权框架，允许用户使用第三方身份认证（如微信、GitHub 登录）。

• CAS（Central Authentication Service）：单点登录（SSO）解决方案，允许用户在多个系统间无缝登录。

本篇文章重点介绍 OAuth2 和 CAS 这两种身份认证方案的原理、实现方式及适用场景。

OAuth2 简介

OAuth2（Open Authorization 2.0） 是一种开放标准的授权框架，允许用户授权第三方应用访问其资源，而无需暴露密码。它的核心思想是基于 令牌（Token） 进行访问控制，避免传统账号密码的安全问题。

OAuth2 主要涉及四种角色：

1. 资源所有者（Resource Owner）：用户，授权第三方访问其受保护资源。

2. 资源服务器（Resource Server）：存储受保护资源的服务器（如 API）。

3. 授权服务器（Authorization Server）：负责用户身份认证，并颁发访问令牌（Access Token）。

4. 客户端（Client）：第三方应用，请求授权后使用令牌访问资源服务器。

OAuth2 认证流程

OAuth2 主要有四种授权模式，最常见的是 授权码模式（Authorization Code），其流程如下：

1. 用户访问客户端（如 GitHub 登录按钮）。

2. 客户端引导用户跳转至授权服务器（OAuth2 认证地址），并传递 client_id、redirect_uri 等信息。

3. 用户登录并授权，授权服务器返回授权码（Authorization Code）。

4. 客户端携带授权码向授权服务器申请访问令牌（Access Token）。授权服务器验证后，返回 Access Token，客户端即可使用令牌访问资源服务器（API）。

SpringSecurity实现OAuth2认证

Spring Security 提供了完整的 OAuth2 支持，以下是一个使用 Spring Boot 搭建 OAuth2 授权服务器的示例。

CAS 介绍

CAS（中央认证服务）是 单点登录（SSO） 解决方案，主要用于企业级应用，使用户只需登录一次即可访问多个系统，而无需重复输入账号密码。

CAS 认证流程

1. 用户访问子系统A，系统 A 检测到用户未登录，跳转至 CAS 服务器认证。

2. 用户在CAS 服务器登录，成功后 CAS 服务器生成 票据（TGT, Ticket Granting Ticket） 并存入 Cookie。

3. CAS服务器生成服务票据（ST, Service Ticket），返回给系统 A。

4. 系统A携带ST向CAS服务器验证，成功后系统 A 允许用户访问。用户访问子系统 B，B 发现用户 Cookie 中已有 TGT，无需重复登录，直接获取 ST 并验证，成功后用户可无缝访问。

多维度OAuth2和CAS区别对照图

建议使用场景

OAuth2适合：移动端、API 授权、第三方登录（如 GitHub、微信授权）。

CAS适合：企业内部单点登录，多个 Web 系统共享登录状态。‍