CAS、OAuth2.0、OIDC、SAML、JWT
CAS
1、CAS协议是什么？
CAS（Central Authentication Service）协议是一种用于Web应用的单点登录（Single Sign-On, SSO）解决方案。它的主要特点和功能包括：
- 单点登录：用户只需要进行一次身份验证，就可以访问多个相互信任的应用系统，无需对每个系统单独进行身份验证。
- 基于票证的认证机制：CAS协议采用票证（Ticket）作为用户身份的证明，而不是直接使用用户名和密码。这种方式提高了安全性，因为敏感信息不会在不同服务间传递。
- 集中式管理：CAS服务器作为集中式的认证中心，负责用户的认证工作。所有需要认证的应用程序都依赖于这个中心来验证用户的身份。
- 独立性和开放性：CAS协议是独立的，不依赖于特定的技术平台或语言。同时，它也是一个开放标准，任何人都可以根据其规范实现自己的CAS客户端或服务器。
- 增强的安全性：除了基本的单点登录功能外，CAS协议还提供了额外的安全特性，比如支持多因素认证、会话管理和安全的票证处理等。
- 用户属性支持：最新的CAS协议规范增强了对用户属性的支持，可以通过新的端点返回用户的详细信息，这有助于应用程序根据用户的特定属性提供个性化的服务。
2、CAS协议具体的认证流程
- 用户请求受保护资源
- 用户访问应用：用户尝试访问一个受保护的资源（例如，某个Web应用中的页面）。
- 应用检查认证状态：应用检查用户是否已经通过CAS认证。如果用户未认证，则应用会将用户重定向到CAS服务器的登录页面。
- 重定向到CAS登录页面
- 应用生成重定向URL：应用生成一个重定向URL，该URL指向CAS服务器的登录页面，并附带一个服务参数（service），该参数包含了用户最初请求的URL。
- 用户重定向到CAS登录页面：应用将用户重定向到CAS服务器的登录页面。
- 用户登录
- 用户输入凭证：用户在CAS登录页面输入用户名和密码。
- CAS服务器接收凭证：CAS服务器接收用户提交的凭证。
- CAS服务器验证凭证
- 验证凭证：CAS服务器验证用户提供的凭证。如果凭证有效，CAS服务器会生成一个票据授予票据（Ticket Granting Ticket, TGT），并将其存储在服务器端。
- 生成服务票据：CAS服务器生成一个服务票据（Service Ticket, ST），并将ST返回给用户。
- 用户携带ST返回应用
- 用户重定向回应用：用户携带ST返回到最初请求的应用。
- 应用接收ST：应用接收到用户携带的ST。
- 应用验证ST
- 应用发送ST到CAS服务器：应用将ST发送回CAS服务器进行验证，并附带最初的服务参数（service）。
- CAS服务器验证ST：CAS服务器验证ST的有效性。如果ST有效，CAS服务器会返回一个包含用户信息的响应给应用。
- 应用授权访问
- 应用接收用户信息：应用根据CAS服务器返回的用户信息，决定是否允许用户访问受保护的资源。
- 用户访问资源：如果用户被授权，应用允许用户访问请求的资源。
- 单点注销（可选）
- 用户请求注销：用户可能在某个应用中请求注销。
- 应用发起注销请求：应用将用户重定向到CAS服务器的注销页面。
- CAS服务器注销TGT：CAS服务器注销用户的TGT，并向所有已注册的应用发送注销通知。
- 应用处理注销通知：各应用接收到注销通知后，清除用户的会话信息，确保用户从所有应用中注销。
OAuth2.0
1、OAuth2.0是什么？
OAuth 2.0 是一种广泛使用的授权框架，用于第三方应用获取有限访问权限，以代表用户访问其在其他服务上的数据。它提供了一种标准化的方法，使得应用程序能够在不暴露用户凭据的情况下，获得对用户资源的访问权限。OAuth 2.0 主要用于以下场景：
- 第三方应用访问用户数据：允许第三方应用在用户授权的情况下访问用户在其他服务上的数据，例如社交媒体账户、电子邮件等。
- API 访问控制：为API提供安全的访问控制机制，确保只有授权的应用能够调用API。
- 单点登录（SSO）：虽然OAuth 2.0 主要用于授权，但它也可以与OpenID Connect结合使用，实现单点登录功能。
OAuth 2.0 的核心概念
- 授权服务器（Authorization Server）：负责验证用户身份并颁发访问令牌（Access Token）。
- 资源服务器（Resource Server）：存储用户数据的服务器，通过访问令牌来验证请求的合法性。
- 客户端（Client）：请求访问用户资源的第三方应用。
- 资源所有者（Resource Owner）：通常是指用户，拥有资源的所有权。
- 访问令牌（Access Token）：客户端用来访问资源服务器上的受保护资源的令牌。
- 刷新令牌（Refresh Token）：用于在访问令牌过期后获取新的访问令牌。
2、OAuth2.0协议具体的认证流程
1. 授权码模式（Authorization Code）
- 详细步骤
- 用户请求访问资源：用户尝试访问受保护的资源。
- 客户端重定向用户到授权服务器：客户端将用户重定向到授权服务器的授权端点，并附带client_id、redirect_uri、scope等参数。
- 用户输入凭证并授权：用户在授权服务器上输入凭证并授权客户端访问其资源。
- 授权服务器重定向用户回客户端：授权服务器验证用户凭证和授权请求后，将用户重定向回客户端，并附带一个授权码（authorization_code）。
- 客户端请求访问令牌：客户端使用授权码向授权服务器请求访问令牌（access_token），并附带client_id、client_secret、redirect_uri和code。
- 授权服务器返回访问令牌：授权服务器验证授权码和其他参数后，返回访问令牌和刷新令牌（refresh_token）。
- 客户端请求资源：客户端使用访问令牌向资源服务器请求受保护的资源。
- 资源服务器返回资源：资源服务器验证访问令牌后，返回资源。
2. 隐式模式（Implicit）
- 详细步骤
- 用户请求访问资源：用户尝试访问受保护的资源。
- 客户端重定向用户到授权服务器：客户端将用户重定向到授权服务器的授权端点，并附带client_id、redirect_uri、scope和response_type=token参数。
- 用户输入凭证并授权：用户在授权服务器上输入凭证并授权客户端访问其资源。
- 授权服务器重定向用户回客户端：授权服务器验证用户凭证和授权请求后，将用户重定向回客户端，并附带访问令牌（access_token）。
- 客户端请求资源：客户端使用访问令牌向资源服务器请求受保护的资源。
- 资源服务器返回资源：资源服务器验证访问令牌后，返回资源。
3. 客户端凭证模式（Client Credentials）
- 详细步骤
- 客户端请求访问令牌：客户端直接向授权服务器请求访问令牌，并附带client_id、client_secret和grant_type=client_credentials。
- 授权服务器返回访问令牌：授权服务器验证客户端凭证后，返回访问令牌。
- 客户端请求资源：客户端使用访问令牌向资源服务器请求受保护的资源。
- 资源服务器返回资源：资源服务器验证访问令牌后，返回资源。
4. 密码模式（Resource Owner Password Credentials）
- 详细步骤
- 用户提供凭证：用户向客户端提供用户名和密码。
- 客户端请求访问令牌：客户端直接向授权服务器请求访问令牌，并附带client_id、client_secret、username、password和grant_type=password。
- 授权服务器返回访问令牌：授权服务器验证用户凭证后，返回访问令牌和刷新令牌。
- 客户端请求资源：客户端使用访问令牌向资源服务器请求受保护的资源。
- 资源服务器返回资源：资源服务器验证访问令牌后，返回资源。
OIDC
OIDC协议是什么？
OIDC（OpenID Connect）是一种基于OAuth 2.0的简单身份验证层，用于验证用户身份并获取用户的基本信息。OIDC扩展了OAuth 2.0的授权框架，使其不仅能够授权访问资源，还能提供用户身份验证和用户信息交换的功能。OIDC 主要用于单点登录（SSO）和用户信息管理。
OIDC的核心概念
- 身份提供者（Identity Provider, IdP）：负责验证用户身份并发放ID Token。
- 客户端（Client）：请求用户身份验证的应用程序。
- 用户代理（User Agent）：通常是用户的浏览器，用于与IdP和客户端进行交互。
- ID Token：一个JWT（JSON Web Token），包含用户的身份信息，用于验证用户身份。
- 访问令牌（Access Token）：用于访问受保护的资源。
- 用户信息端点（Userinfo Endpoint）：提供用户详细信息的API端点。
OIDC的主要功能
- 用户身份验证：通过IdP验证用户身份，并返回ID Token。
- 用户信息交换：通过用户信息端点获取用户的详细信息。
- 单点登录（SSO）：用户在一个应用中登录后，可以无缝访问其他应用，无需再次登录。
- 单点注销（SLO）：用户在一个应用中注销后，可以从所有关联的应用中注销。
OIDC协议具体的认证流程
1. 授权码模式（Authorization Code）
- 详细步骤
- 用户请求访问资源：用户尝试访问受保护的资源。
- 客户端重定向用户到IdP：客户端将用户重定向到IdP的授权端点，并附带client_id、redirect_uri、scope和response_type=code参数。
- 用户输入凭证并授权：用户在IdP上输入凭证并授权客户端访问其资源。
- IdP重定向用户回客户端：IdP验证用户凭证和授权请求后，将用户重定向回客户端，并附带一个授权码（authorization_code）。
- 客户端请求ID Token和Access Token：客户端使用授权码向IdP请求ID Token和Access Token，并附带client_id、client_secret、redirect_uri和code。
- IdP返回ID Token和Access Token：IdP验证授权码和其他参数后，返回ID Token和Access Token。
- 客户端请求资源：客户端使用Access Token向资源服务器请求受保护的资源。
- 资源服务器返回资源：资源服务器验证Access Token后，返回资源。
2. 隐式模式（Implicit）
- 详细步骤
- 用户请求访问资源：用户尝试访问受保护的资源。
- 客户端重定向用户到IdP：客户端将用户重定向到IdP的授权端点，并附带client_id、redirect_uri、scope和response_type=id_token token参数。
- 用户输入凭证并授权：用户在IdP上输入凭证并授权客户端访问其资源。
- IdP重定向用户回客户端：IdP验证用户凭证和授权请求后，将用户重定向回客户端，并附带ID Token和Access Token。
- 客户端请求资源：客户端使用Access Token向资源服务器请求受保护的资源。
- 资源服务器返回资源：资源服务器验证Access Token后，返回资源。
SAML
1、SAML协议是什么？
SAML（Security Assertion Markup Language，安全断言标记语言）是一种基于XML的标准，用于在不同安全域之间交换身份验证和授权数据。SAML 主要用于单点登录（SSO）和身份验证，使得用户可以在多个应用和服务之间无缝切换，而无需重复输入凭证。
SAML的核心概念
- 身份提供者（Identity Provider, IdP）：负责验证用户身份并生成SAML断言（Assertion）。
- 服务提供者（Service Provider, SP）：依赖于IdP进行用户身份验证的应用或服务。
- 用户代理（User Agent）：通常是用户的浏览器，用于与IdP和SP进行交互。
- SAML断言（Assertion）：包含用户身份信息的XML文档，由IdP生成并发送给SP。
- SAML请求（Request）：SP 发送给IdP的请求，用于启动身份验证流程。
- SAML响应（Response）：IdP 发送给SP的响应，包含SAML断言。
2、SAML协议具体的认证流程
详细步骤
- 用户请求访问资源
- 用户尝试访问一个受保护的资源，例如某个Web应用中的页面。
- SP检查用户是否已经通过身份验证。如果用户未认证，则SP会生成一个SAML请求。
- SP生成SAML请求
- SP生成一个SAML请求，包含必要的参数，如SP的实体ID、目标URL等。
- SP将SAML请求编码为Base64或Deflate格式，以便通过HTTP POST或Redirect方式传输。
- SP将用户重定向到IdP的登录页面，并附带编码后的SAML请求。
- 用户在IdP进行身份验证
- 用户在IdP的登录页面输入用户名和密码。
- IdP验证用户提供的凭证。如果凭证有效，IdP会生成一个SAML断言。
- IdP生成SAML断言
- IdP生成一个包含用户身份信息的SAML断言，包括用户标识、身份验证时间等。
- IdP将SAML断言编码为Base64或Deflate格式，以便通过HTTP POST或Redirect方式传输。
- IdP将用户重定向回SP，并附带编码后的SAML断言。
- SP验证SAML断言
- SP接收到用户携带的SAML断言。
- SP验证SAML断言的签名和内容，确保断言的有效性和完整性。
- 如果SAML断言有效，SP会创建一个会话，表示用户已成功认证。
- 用户访问资源
- SP根据用户身份信息，决定是否允许用户访问受保护的资源。
- 如果用户被授权，SP允许用户访问请求的资源。
JWT
1、JWT协议是什么？
JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在网络应用环境间安全地传输信息。JWT 以 JSON 对象的形式存在，通常用于身份验证和信息交换。JWT 包含三个部分：头部（Header）、载荷（Payload）和签名（Signature）。
- JWT 的组成部分
1. 头部（Header）
包含令牌的类型（通常是“JWT”）和所使用的签名算法（如HMAC SHA256或RSA）。
示例：
{
"alg": "HS256",
"typ": "JWT"
}
2. 载荷（Payload）
- 包含声明（claims），即实际要传递的数据。声明可以是预定义的，也可以是自定义的。
- 预定义声明包括：
- iss（issuer）：签发者
- sub（subject）：主题
- aud（audience）：受众
- exp（expiration time）：过期时间
- nbf（not before）：生效时间
- iat（issued at）：签发时间
- jti（JWT ID）：唯一标识符
自定义声明可以根据需求添加任何数据。
示例：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
3.签名（Signature）
用于验证消息在传输过程中没有被篡改，并且可以确认签发者的身份。
签名通过以下方式生成：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
示例：
HMACSHA256(
eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9 +
eyJzdWIiOiAiMTIzNDU2Nzg5MCIsICJuYW1lIjogIkpvaG4gRG9lIiwgImFkbWluIjogdHJ1ZX0,
your-256-bit-secret
)
- JWT 的特点
- 紧凑：JWT 是紧凑的，适合在 URL、POST 参数或 HTTP 头中传输。
- 自包含：JWT 包含所有必要信息，减少了数据库查询的需要。
- 安全：通过签名确保信息的完整性和真实性。
2、JWT协议的具体认证流程
详细步骤
- 用户登录
- 用户通过表单或其他方式提交用户名和密码。
- 服务器验证用户提交的凭证。如果凭证有效，服务器生成一个 JWT。
- 服务器将生成的 JWT 返回给客户端，通常通过 HTTP 响应头（如 Authorization）或响应体。
- 客户端存储 JWT
- 客户端将收到的 JWT 存储在本地存储（如浏览器的 localStorage 或 sessionStorage）或内存中。
- 客户端发送 JWT
- 客户端在后续请求中将 JWT 包含在 HTTP 请求头中，通常使用 Authorization 头。
Authorization: Bearer <token>
- 服务器验证 JWT
- 服务器从请求头中提取 JWT。
- 服务器验证 JWT 的签名，确保 JWT 没有被篡改。服务器还会检查 JWT 的过期时间和生效时间。
- 如果 JWT 有效，服务器处理请求并返回响应。
- 用户访问资源
- 用户通过带有有效 JWT 的请求访问受保护的资源。
- 服务器验证 JWT 后，返回请求的资源。
扫一扫
296
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
