同步操作将从 turnon/blog 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
title: 认证设计
date: 2022-11-15 18:04:17
categories:
- 设计
- 架构
- 安全
tags:
- 架构
- 安全
- 认证
permalink: /pages/6236e0/
认证 (Authentication) 是根据凭据验明访问者身份的流程。即验证“你是你所说的那个人”的过程。
身份认证,通常通过用户名/邮箱/手机号以及密码匹配来完成,也可以通过手机/邮箱验证码或者生物特征(如:指纹、虹膜)等其他因素。在某些应用系统中,为了追求更高的安全性,往往会要求多种认证因素叠加使用,这就是我们经常说的多因素认证。
常见的认证方式
授权 (Authorization) 是指向经过身份认证的访问者授予执行某项操作的权限(如访问资源,执行文件/数据读写权限等)。 简言之,授权是验证“你被允许做你想做的事”的过程。
虽然授权通常在身份验证后立即发生(例如,登录计算机系统时),但这并不意味着授权以身份验证为前提:匿名代理可以被授权执行有限的操作集。
由于 Http 是一种无状态的协议,服务器单从网络连接上无从知道客户身份。会话跟踪是 Web 程序中常用的技术,用来跟踪用户的整个会话。常用会话跟踪技术是 Cookie 与 Session。
Cookie 实际上是存储在客户端上的文本信息,并保留了各种跟踪的信息。
Cookie 保存在客户端浏览器中,而 Session 保存在服务器上。如果说 Cookie 机制是通过检查客户身上的“通行证”来确定客户身份的话,那么 Session 机制就是通过检查服务器上的“客户明细表”来确认客户身份。
SSO(Single Sign On),即单点登录。所谓单点登录,就是同平台的诸多应用登陆一次,下一次就免登陆的功能。
SSO 需要解决多个异构系统之间的问题:
分布式 Session 的几种实现策略:
详情请参考:Session 原理
Cookie 不能跨域!比如:浏览器不会把 www.google.com 的 cookie 传给 www.baidu.com。
这就存在一个问题:由于域名不同,用户在系统 A 登录后,浏览器记录系统 A 的 Cookie,但是访问系统 B 的时候不会携带这个 Cookie。
针对 Cookie 不能跨域 的问题,有几种解决方案:
SessionStroage
中(不依赖 Cookie 就没有跨域的问题了)。CAS 是实现 SSO 的主流方式。
CAS 分为两部分,CAS Server 和 CAS Client
CAS Server
- 负责用户的认证工作,就像是把第一次登录用户的一个标识存在这里,以便此用户在其他系统登录时验证其需不需要再次登录。CAS Client
- 业务应用,需要接入 CAS Server。当用户访问我们的应用时,首先需要重定向到 CAS Server 端进行验证,要是原来登陆过,就免去登录,重定向到下游系统,否则进行用户名密码登陆操作。术语:
Ticket Granting Ticket (TGT)
- 可以认为是 CAS Server 根据用户名、密码生成的一张票,存在 Server 端。Ticket Granting Cookie (TGC)
- 其实就是一个 Cookie,存放用户身份信息,由 Server 发给 Client 端。Service Ticket (ST)
- 由 TGT 生成的一次性票据,用于验证,只能用一次。CAS 工作流程:
以上了归纳总结如下:
JSON Web Token (JWT,RFC 7519 (opens new window)),是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准((RFC 7519)。该 token 被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该 token 也可直接被用于认证,也可被加密。
详细内容可以参考这篇文章:什么是 JWT (opens new window)。
OAuth 是一个关于授权(Authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是 2.0 版。
简单来说,OAuth 是一种授权机制。资源的所有者告诉系统,同意授权第三方应用进入系统,访问这些资源。系统从而产生一个短期的进入令牌(token),用来代替密码,供第三方应用使用。
客户端必须得到用户的授权(authorization grant),才能获得令牌(access token)。
OAuth 2.0 定义了四种授权方式。
授权码(authorization code)方式,指的是第三方应用先申请一个授权码,然后再用该授权码获取令牌。
这种方式是最常用的流程,安全性也最高,它适用于那些有后端的 Web 应用。授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏。
有些 Web 应用是纯前端应用,没有后端。这时就不能用上面的方式了,必须将令牌储存在前端。RFC 6749 就规定了第二种方式,允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤,所以称为(授权码)"隐藏式"(implicit)。
如果你高度信任某个应用,RFC 6749 也允许用户把用户名和密码,直接告诉该应用。该应用就使用你的密码,申请令牌,这种方式称为"密码式"(password)。
适用于没有前端的命令行应用,即在命令行下请求令牌。
如果用户访问的时候,客户端的"访问令牌"已经过期,则需要使用"更新令牌"申请一个新的访问令牌。
客户端发出更新令牌的 HTTP 请求,包含以下参数:
ID Token 相当于用户的身份凭证,开发者的前端访问后端接口时可以携带 ID Token,开发者服务器可以校验用户的 ID Token 以确定用户身份,验证通过后返回相关资源。
ID Token 本质上是一个 JWT Token
,包含了该用户身份信息相关的 key/value 键值对,例如:
{
"iss": "https://server.example.com",
"sub": "24400320", // subject 的缩写,为用户 ID
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}
ID Token 本质上是一个 JWT Token 意味着:
用户的身份信息直接被编码进了 id_token,你不需要额外请求其他的资源来获取用户信息;
id_token 可以验证其没有被篡改过,详情请见如何验证 ID Token。
Access Token 用于基于 Token 的认证模式,允许应用访问一个资源 API。用户认证授权成功后,认证系统会签发 Access Token 给应用。应用需要携带 Access Token 访问资源 API,资源服务 API 会通过拦截器查验 Access Token 中的 scope
字段是否包含特定的权限项目,从而决定是否返回资源。
如果你的用户通过社交账号登录,例如微信登录,微信作为身份提供商会颁发自己的 Access Token,你的应用可以利用 Access Token 调用微信相关的 API。这些 Access Token 是由社交账号服务方控制的,格式也是任意的。
AccessToken 和 IdToken 是 JSON Web Token (opens new window),有效时间通常较短。通常用户在获取资源的时候需要携带 AccessToken,当 AccessToken 过期后,用户需要获取一个新的 AccessToken。
Refresh Token 用于获取新的 AccessToken。这样可以缩短 AccessToken 的过期时间保证安全,同时又不会因为频繁过期重新要求用户登录。
用户在初次认证时,Refresh Token 会和 AccessToken、IdToken 一起返回。你的应用必须安全地存储 Refresh Token,它的重要性和密码是一样的,因为 Refresh Token 能够一直让用户保持登录。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。