双因素认证

一般有以下三种方式进行身份认证

秘密认证：例如常见的用户名密码，秘密问题等（QQ早期找回密码需要回答之前设置好的秘密问题，第一个宠物的名字等等）
私人物品认证：例如身份证，信物（玉佩），手机、U盾等
生理认证：视网膜，人脸，指纹等

同时采用以上任意两种的认证方式进行认证，就是双因素认证。一般最常见的是秘密+私人物品。

银行之前使用的U盾就是私人物品，随着智能手机的流行，手机成为一个人必不可少的物品，U盾被代替。

OAuth 2.0 and OpenID Connect

视频学习资料https://www.youtube.com/watch?v=996OiexHze0

• OpenID Connect is for authentication
• OAuth 2.0 is for authorization

OIDC是OpenID Connect的简称，OIDC=(Identity, Authentication) + OAuth 2.0。它在OAuth2上构建了一个身份层，是一个基于OAuth2协议的身份认证标准协议。

OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题；OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。OIDC的核心在于在OAuth2的授权流程中，一并提供用户的身份认证信息（ID Token）给到第三方客户端，ID Token使用JWT格式来包装，得益于JWT（JSON Web Token）的自包含性，紧凑性以及防篡改机制，使得ID Token可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了UserInfo的接口，用户获取用户的更完整的信息。

OAuth授权

Authorization code flow

Implicit flow

OAuth 2.0 四种模式
http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
https://learnku.com/articles/20082

OpenID Connect认证

Screen Shot 2020-11-27 at 9.23.46 AM.png

OIDC在OAuth2.0之上增加了ID token包含用户信息

Screen Shot 2020-11-27 at 9.25.09 AM.png

Session与JWT

Session

1、用户向服务器发送用户名和密码。
2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3、服务器向用户返回一个 session_id，写入用户的 Cookie。
4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。
这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。

举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？

一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。

另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。

JWT

1、用户向服务器发送用户名和密码。
2、服务器验证通过后，返回包含用户权限、过期时间的JWT token。
3、客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。
4、服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

JWT 的三个部分依次如下。

Header（头部）
Payload（负载）
Signature（签名）

Header包含

• alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）
• typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT

Payload包含

• iss (issuer)：签发人
• exp (expiration time)：过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

可以自定义字段
这个 JSON 对象也要使用 Base64URL 算法转成字符串。

Signature签名

Signature 部分是对前两部分的签名，防止数据篡改。

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Spring-Security 学习

Spring Security Demo

Video https://www.youtube.com/watch?v=her_7pa0vrg

git@github.com:amigoscode/spring-boot-security-course.git

常用的 Http 认证方式

HTTP Basic Authentication

HTTP Basic Authentication 又叫基础认证，它简单地使用 Base64 算法对用户名、密码进行加密，并将加密后的信息放在请求头 Header 中，本质上还是明文传输用户名、密码，并不安全，所以最好在 Https 环境下使用。

Form 表单认证

Form 表单的认证方式并不是HTTP规范。所以实现方式也呈现多样化，其实我们平常的扫码登录，手机验证码登录都属于表单登录的范畴。表单认证一般都会配合 Cookie，Session 的使用，现在很多 Web 站点都使用此认证方式。用户在登录页中填写用户名和密码，服务端认证通过后会将 sessionId 返回给浏览器端，浏览器会保存 sessionId 到浏览器的 Cookie 中。因为 HTTP 是无状态的，所以浏览器使用 Cookie 来保存 sessionId。下次客户端会在发送的请求中会携带 sessionId 值，服务端发现 sessionId 存在并以此为索引获取用户存在服务端的认证信息进行认证操作。认证过则会提供资源访问。

我们在Spring Security 实战干货：登录后返回 JWT Token 一文其实也是通过 Form 提交来获取 Jwt 其实 Jwt 跟 sessionId 同样的作用，只不过 Jwt 天然携带了用户的一些信息，而 sessionId 需要去进一步获取用户信息。

Json Web Token 的认证方式 Bearer Authentication

我们通过表单认证获取 Json Web Token ，那么如何使用它呢? 通常我们会把 Jwt 作为令牌使用 Bearer Authentication 方式使用。Bearer Authentication 是一种基于令牌的 HTTP 身份验证方案，用户向服务器请求访问受限资源时，会携带一个 Token 作为凭证，检验通过则可以访问特定的资源。最初是在 RFC 6750 中作为 OAuth 2.0 的一部分，但有时也可以单独使用。我们在使用 Bear Token 的方法是在请求头的 Authorization 字段中放入 Bearer <token> 的格式的加密串(Json Web Token)。请注意 Bearer 前缀与 Token 之间有一个空字符位，与基本身份验证类似，Bearer Authentication 只能在HTTPS（SSL）上使用。