[요약 공유] 일반적으로 사용되는 프런트엔드 및 백엔드 인증 방법 10가지, 더 이상 헷갈리지 마세요

권한 제어란 무엇인가요?

인증, 승인, 인증, 권한 제어는 어떤 관계인가요?

• 출입카드를 이용해 문을 여는 방법: 인증, 승인, 인증, 권한 제어의 4가지 링크가 통합되어 순식간에 동시에 발생합니다.
• 사용자의 웹사이트 로그인: 사용자가 사용자를 사용하여 로그인할 때 이름과 비밀번호, 인증과 승인 모두 각 링크가 함께 완료되며, 항목 선택이나 결제 등 후속 접근 요청 시 인증과 권한 제어가 발생합니다.

다음은 모두가 생각해 볼 수 있는 작은 질문입니다. 인증과 인증의 관계는 무엇인가요? 누구나 댓글 영역에서 토론할 수 있습니다

이제 둘 사이의 관계를 이해했으므로 프런트 엔드 인증에 대해 이야기해야 할까요? 그리고 그들 사이의 차이점은 무엇입니까?

1. HTTP 기본 인증

HTTP에서는 기본 액세스 인증)을 통해 클라이언트(일반적으로 웹 브라우저)가 사용자의 신원을 확인하기 위해 사용자 이름과 비밀번호를 제공합니다.
基本认证方案（Basic Access Authentication) 是允许客户端（通常指的就是网页浏览器）在请求时，通过用户提供用户名和密码的方式，实现对用户身份的验证。

因为几乎所有的线上网站都不会走该认证方案，所以该方案大家了解即可

1.1 认证流程图

1.2 认证步骤解析

• 客户端(如浏览器)： 向服务器请求一个受限的列表数据或资源，例如字段如下

   GET /list/ HTTP/1.1
   Host: www.baidu.com
   Authorization: Basic aHR0cHdhdGNoOmY=

  로그인 후 복사

• 服务器：客户端你好，这个资源在安全区 baidu.com 里，是受限资源，需要基本认证；

  并且向客户端返回 401 状态码（Unauthorized 未被授权的）以及附带提供了一个认证域 www-Authenticate: Basic realm=”baidu.com”要求进行身份验证；

  其中Basic 就是验证的模式，而 realm="baidu.com" 说明客户端需要输入这个安全域的用户名和密码，而不是其他域的

   HTTP/1.1 401 Unauthorized
   www-Authenticate: Basic realm= "baidu.com"

  로그인 후 복사

• 客户端： 服务器，我已经携带了用户名和密码给你了，你看一下；（注：如客户端是浏览器，那么此时会自动弹出一个弹窗，让用户输入用户名和密码）；

  输入完用户名和密码后，则客户端将用户名及密码以 Base64 加密方式发送给服务器

  传送的格式如下 (其中 Basic 内容为：用户名:密码 的 ase64 形式)：

   GET /list/ HTTP/1.1 
   Authorization: Basic Ksid2FuZzp3YW5n==

  로그인 후 복사

• 服务器： 客户端你好，我已经校验了Authorization 字段你的用户名和密码，是正确的，这是你要的资源。

   HTTP/1.1 200 OK
   ...

  로그인 후 복사

1.3 优点

简单，基本所有流行的浏览器都支持

1.4 缺点

• 不安全：

  • 由于是基于 HTTP 传输，所以它在网络上几乎是裸奔的，虽然它使用了 Base64 来编码，但这个编码很容易就可以解码出来。
  • 即使认证内容无法被解码为原始的用户名和密码也是不安全的，恶意用户可以再获取了认证内容后使用其不断的享服务器发起请求，这就是所谓的重放攻击。

• 无法主动注销：

  • 由于 HTTP 协议没有提供机制清除浏览器中的 Basic 认证信息，除非标签页或浏览器关闭、或用户清除历史记录。

1.5 使用场景

内部网络，或者对安全要求不是很高的网络。

2. Session-Cookie 鉴权

Session-Cookie 认证是利用服务端的 Session（会话）和 浏览器（客户端） 的 Cookie 来实现的前后端通信认证模式。

在理解这句话之前我们先简单了解下 什么是 Cookie 以及 什么是 Session ？

2.1 什么是 Cookie

众所周知，HTTP 是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）；

所以为了让服务器区分不同的客户端，就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态可以通过 Cookie

거의 모든 온라인 웹사이트에서는 이 인증 방식을 사용하지 않으므로 누구나 이 방식을 이해할 수 있습니다

🎜🎜🎜클라이언트(예: 브라우저): 🎜 서버에서 제한된 목록 데이터 또는 리소스를 요청하세요. 예를 들어 필드는 다음과 같습니다🎜

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

 {
   "alg": "HS256",
   "typ": "JWT"
 }

 {
   "sub": "1234567890",
   "name": "John Doe",
   "admin": true
 }

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

🎜🎜🎜Unsafe: 🎜🎜🎜🎜HTTP 전송 기반이므로 네트워크상에서는 거의 안전하지 않습니다. , Base64를 사용하여 인코딩하지만 이 인코딩은 쉽게 디코딩할 수 있습니다. 🎜🎜인증 내용을 원래 사용자 이름과 비밀번호로 해독할 수 없더라도 안전하지 않습니다. 악의적인 사용자가 인증 내용을 획득한 후 지속적인 공유 서버를 사용하여 요청을 시작할 수 있습니다. 🎜🎜🎜🎜🎜🎜적극적으로 로그아웃할 수 없습니다🎜: 🎜🎜🎜HTTP 프로토콜은 탭이나 브라우저를 닫거나 사용자가 기록을 지우지 않는 한 브라우저에서 기본 인증 정보를 지우는 메커니즘을 제공하지 않습니다. 🎜🎜🎜🎜🎜🎜1.5 사용 시나리오🎜🎜🎜내부 네트워크 또는 보안 요구 사항이 매우 높지 않은 네트워크. 🎜🎜🎜2. 세션-쿠키 인증 🎜🎜🎜🎜Session-Cookie 인증은 서버의 Session(세션)과 Cookie를 이용하여 구현한 Front-End 및 Back-End 통신 인증 방식입니다. 브라우저(클라이언트)의 .
🎜🎜이 문장을 이해하기 전에 쿠키란 무엇인가와 세션이란 무엇인가에 대해 간단히 알아보고 가볼까요? 🎜🎜🎜2.1 쿠키란 무엇입니까🎜🎜🎜우리 모두 알고 있듯이 HTTP는 상태 비저장 프로토콜입니다(트랜잭션을 위한 메모리 용량 없음) 처리, 클라이언트와 서버 간의 세션이 완료될 때마다 서버는 세션 정보를 저장하지 않습니다.) 🎜🎜따라서 서버가 서로 다른 클라이언트를 구별하려면 다음과 같은 상태를 적극적으로 유지해야 합니다. 두 요청이 동일한 브라우저에서 오는지 전후에 서버에 알립니다. 이 상태는 쿠키를 통해 얻을 수 있습니다. 🎜🎜🎜특징:🎜🎜
• 쿠키는 클라이언트 측에 저장되며 임의로 변경될 수 있습니다.
• 최대 4kb까지만 저장할 수 있습니다. 웹사이트당 쿠키는 20개 이하입니다. 브라우저는 일반적으로 300개의 쿠키만 허용합니다.
• Android 및 IOS는 쿠키를 잘 지원하지 않습니다.
• 쿠키는 도메인 간이 아니지만 1단계 도메인 이름과 2단계 도메인 이름은 공유 허용 (도메인에 따라 다름)

2.2 세션이란 무엇입니까 세션의 추상적 개념은 세션입니다. 이는 중단을 실현하기 위해 사용자와 서버 간의 상호 작용을 추상화한 것입니다. /Stateless 프로토콜 통신 과정 중 연속 작업

구체적으로는 서버입니다. 생성된 세션 구조는 메모리, 데이터베이스, 파일 등 다양한 방법으로 저장할 수 있습니다. 대규모 웹사이트에는 일반적으로 전용 세션 서버 클러스터가 있습니다.

원칙 프로세스:
• 클라이언트:

  사용자가 처음으로 서버에 요청을 보냅니다.

• 서버:

  데이터를 수신하고 자동으로 특정 세션을 생성합니다. 사용자를 식별하고 사용자의 현재 세션 프로세스를 추적하기 위한 세션 ID

• Customer End:

  브라우저는 세션 정보를 얻기 위한 응답을 받고 다음 요청 시 세션/세션 ID를 가져옵니다.

• 서버:

  서버는 이를 추출한 후 로컬에 저장된 세션 ID와 비교하여 특정 사용자의 세션을 찾은 다음 세션 상태를 얻습니다.

클라이언트와 서버 간의 통신 이제 상태 저장 통신이 되었습니다.
세션이 서버에 저장됩니다.

프로토콜이 수행됩니다.

과 쿠키의 차이점:
• 보안:
• 쿠키는 클라이언트 측에 저장되며 마음대로 조작할 수 있는 반면, 세션은 서버 측에 저장되어 위조할 수 없으므로 세션이 더 안전합니다.

다양한 유형의 액세스 값: 쿠키 문자열 데이터만 지원하며 세션은 모든 데이터 유형을 저장할 수 있습니다.

다양한 유효 기간:
쿠키는 오랫동안 유지되도록 설정할 수 있으며, 세션은 일반적으로 더 짧은 만료 시간을 갖습니다.
• 다양한 저장 크기: 데이터 쿠키에 의해 저장됨은 4K를 초과할 수 없습니다.
• 이를 보고 일부 학생들은 Session-Cookie가 단지 Session를 사용하는가라고 생각했을 것입니다. 클라이언트의 에 저장되어 있습니까? 쿠키?
• Bingo, 정말 그렇습니다. 아래를 살펴보겠습니다
• 2.3 세션-쿠키 인증 흐름도



Session-Cookie 是不是就是把 Session 存储在了客户端的 Cookie 中呢？

Bingo，的确是这样的，我们接着往下看

2.3 Session-Cookie 的认证流程图



2.4 Session-Cookie 认证步骤解析

• 客户端： 向服务器发送登录信息用户名/密码来请求登录校验；

• 服务器： 验证登录的信息，验证通过后自动创建 Session（将 Session 保存在内存中，也可以保存在 Redis 中），然后给这个 Session 生成一个唯一的标识字符串会话身份凭证 session_id(通常称为 sid)，并在响应头 Set-Cookie 中设置这个唯一标识符；

  注：可以使用签名对 sid 进行加密处理，服务端会根据对应的 secret 密钥进行解密 （非必须步骤）

• 客户端： 收到服务器的响应后会解析响应头，并自动将 sid 保存在本地 Cookie 中，浏览器在下次 HTTP 请求时请求头会自动附带上该域名下的 Cookie 信息；

• 服务器： 接收客户端请求时会去解析请求头 Cookie 中的 sid，然后根据这个 sid 去找服务端保存的该客户端的 sid

2.4 세션-쿠키 인증 단계 분석
고객 클라이언트 :
로그인 확인을 요청하기 위해 로그인 정보 사용자 이름/비밀번호를 서버로 보냅니다.
• 서버:
로그인 정보를 확인하고 확인을 통과한 후 자동으로 세션을 생성합니다(세션을 메모리 또는 Redis에 저장). 이 세션에 대한 고유 식별 문자열 세션 ID 자격 증명 session_id(일반적으로 sid라고 함)를 생성하고 이를 응답 헤더 Set-Cookie<p><span style="font-size: 18px;">참고: 서명을 사용하여 <code>sid를 암호화할 수 있으며, 서버는 해당 비밀 키를 기반으로 이를 해독합니다(선택 사항)
🎜클라이언트: 🎜 서버로부터 응답을 받은 후 응답 헤더를 구문 분석하고 자동으로 로컬 쿠키에 sid를 저장합니다. 브라우저는 다음 HTTP를 사용합니다. 요청 헤더에는 도메인 이름 아래의 쿠키 정보가 자동으로 포함됩니다. 🎜🎜🎜🎜🎜서버: 🎜 클라이언트 요청을 받으면 요청 헤더 쿠키의 sid를 구문 분석합니다. , 그리고 이 sid를 사용하여 서버에 저장된 클라이언트의 sid를 찾은 다음 요청이 합법적인지 확인합니다. 🎜🎜🎜🎜🎜🎜2.5 세션의 장점; -쿠키🎜🎜🎜🎜🎜쿠키는 간단합니다. 사용하기 쉽습니다🎜🎜세션 데이터는 JWT에 비해 관리가 더 쉽습니다. 즉, 사용자가 적극적으로 로그인하고 로그아웃할 때 필요한 것입니다. 해당 세션을 추가하고 삭제하는 것은 쉽습니다🎜🎜백엔드 작업만 필요하며, 프론트엔드는 아무런 의미 없이 운영될 수 있습니다. 🎜🎜2.6 세션 쿠키의 단점🎜🎜🎜
• 쿠키에 의존합니다. 사용자가 브라우저에서 쿠키를 비활성화하면 GG Smecta가 손실됩니다.
• 쿠키는 브라우저에 데이터를 노출하므로 데이터 도난 위험이 높아집니다. );
• 세션이 서버에 저장되므로 사용자 수가 많으면 서버 성능이 크게 저하됩니다.
• 모바일 지원에 적합하지 않습니다. 사용 시나리오

일반적으로 중대형 웹사이트에 적용 가능(APP 모바일 단말기 제외) 일반 세션은 메모리 서버(예: Redis)에 중앙 집중식으로 저장되어야 하므로 서버 예산이 증가합니다. 예산이 부족하다면 신중하게 선택하세요

• 2.8 프론트 엔드에서 일반적으로 사용되는 세션 라이브러리를 권장합니다

express 사용: express-session

koa 사용:
• koa-session
• 3. 토큰 인증

이제 알다시피 Session-Cookie의 몇 가지 단점과 Session의 유지 관리로 인해 서버에 큰 문제가 발생할 수 있습니다. 저장해야 하고 배포 문제도 고려해야 하며 이를 위해 별도의 서버를 활성화해야 합니다. 더 좋은 방법이 있나요?
그러다가 토큰이 탄생했습니다

---

Session-Cookie 的一些缺点，以及 Session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。那有没有更好的办法？


那 Token 就应运而生了

3.1 什么是 Token（令牌）

Token 是一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后，客户端就可以携带令牌访问服务器，服务端只需要验证令牌的有效性即可。

一句话概括；访问资源接口（API）时所需要的资源凭证

一般 Token 的组成：

uid (用户唯一的身份标识) + time (当前时间的时间戳) + sign (签名，Token 的前几位以哈希算法压缩成的一定长度的十六进制字符串)

Token 的认证流程图：



Token 认证步骤解析：

• 客户端： 输入用户名和密码请求登录校验；

• 服务器： 收到请求，去验证用户名与密码；验证成功后，服务端会签发一个 Token 并把这个 Token 发送给客户端；

• 客户端： 收到 Token 以后需要把它存储起来，web 端一般会放在 localStorage 或 Cookie 中，移动端原生 APP 一般存储在本地缓存中；

• 客户端发送请求： 向服务端请求 API 资源的时候，将 Token 通过 HTTP 请求头 Authorization 字段或者其它方式发送给服务端；

• 服务器： 收到请求，然后去验证客户端请求里面带着的 Token ，如果验证成功，就向客户端返回请求的数据，否则拒绝返还（401）；

Token 的优点：

• 服务端无状态化、可扩展性好： Token 机制在服务端不需要存储会话（Session）信息，因为 Token 自身包含了其所标识用户的相关信息，这有利于在多个服务间共享用户状态
• 支持 APP 移动端设备；
• 安全性好： 有效避免 CSRF 攻击（因为不需要 Cookie）
• 支持跨程序调用： 因为 Cookie 是不允许跨域访问的，而 Token 则不存在这个问题

Token 的缺点：

• 配合： 需要前后端配合处理；
• 占带宽： 正常情况下比 sid 更大，消耗更多流量，挤占更多宽带
• 性能问题： 虽说验证 Token 时不用再去访问数据库或远程服务进行权限校验，但是需要对 Token 加解密等操作，所以会更耗性能；
• 有效期短： 为了避免 Token 被盗用，一般 Token 的有效期会设置的较短，所以就有了 Refresh Token；

3.2 什么是 Refresh Token（刷新 Token）

业务接口用来鉴权的 Token，我们称之为 Access Token。

为了安全，我们的 Access Token 有效期一般设置较短，以避免被盗用。但过短的有效期会造成 Access Token 经常过期，过期后怎么办呢？

一种办法是：刷新 Access Token3.1 토큰이란 무엇입니까

🎜🎜🎜토큰은 토큰입니다. 클라이언트가 서버에 접속하면 , 서버는 검증을 통과한 후 토큰을 발급합니다. 그 후 클라이언트는 토큰을 사용하여 서버에 액세스할 수 있으며 서버는 토큰의 유효성만 확인하면 됩니다. 🎜🎜한 문장으로 요약 🎜리소스 인터페이스(API)에 액세스할 때 필요한 리소스 자격 증명 🎜🎜🎜🎜일반 토큰 구성: 🎜🎜🎜🎜uid🎜(사용자 고유 ID) + 🎜time🎜(현재 시간) 스탬프) + 🎜sign🎜 (서명, 토큰의 첫 번째 숫자는 해시 알고리즘을 사용하여 특정 길이의 16진수 문자열로 압축됩니다.) 🎜🎜🎜토큰 인증 흐름도: 🎜🎜🎜🎜🎜🎜토큰 인증 단계 분석: 🎜🎜
🎜🎜🎜클라이언트: 🎜 로그인 확인을 요청하려면 사용자 이름과 비밀번호를 입력하세요. 🎜🎜🎜🎜🎜서버: 🎜 사용자 이름과 비밀번호 확인 요청을 받으면 서버가 발급됩니다. 🎜🎜🎜🎜🎜클라이언트: 🎜 토큰을 받은 후에는 일반적으로 웹 측에서 이를 localStorage 또는 Cookie에 저장해야 하며 모바일 측에서는 기본 앱이 됩니다. 일반적으로 로컬 캐시에 저장됩니다. 🎜🎜🎜🎜🎜클라이언트가 요청을 보냅니다. 🎜 서버에서 API 리소스를 요청할 때 토큰은 HTTP 요청 헤더 인증 필드 또는 기타 방법을 통해 서버로 전송됩니다. 서버: 🎜 요청을 받은 후 클라이언트 요청에 포함된 토큰을 확인합니다. 확인에 성공하면 요청한 데이터가 클라이언트에 반환됩니다. 그렇지 않으면 반환이 거부됩니다(401). 토큰의 장점: 🎜🎜🎜 🎜🎜서버는 상태가 없고 확장 가능합니다. 🎜토큰 메커니즘은 토큰 자체에 식별된 사용자와 관련된 정보가 포함되어 있으므로 서버 측에 세션 정보를 저장할 필요가 없습니다. 이는 서버 간 공유에 도움이 됩니다. 여러 서비스 사용자 상태 🎜🎜🎜APP 모바일 장치 지원 🎜🎜🎜🎜훌륭한 보안: 🎜 CSRF 공격을 효과적으로 방지합니다(쿠키가 필요하지 않기 때문에) 🎜🎜🎜교차 프로그램 호출 지원: 🎜 쿠키는 도메인 간 액세스를 허용하지 않기 때문입니다. , 토큰에는 이 문제가 없습니다🎜🎜🎜🎜토큰의 단점: 🎜🎜🎜🎜🎜협력: 🎜 프런트엔드 및 백엔드 협력이 필요합니다. 🎜🎜🎜점유 대역폭: 🎜 일반적으로 sid보다 큽니다. code>.더 많은 트래픽을 소비하고 더 많은 대역폭을 차지합니다🎜🎜🎜성능 문제:🎜 토큰 검증 시 권한 확인을 위해 데이터베이스나 원격 서비스에 접속할 필요는 없지만 토큰의 암호화, 복호화 등의 작업이 필요하므로 더 많은 성능을 소모합니다.🎜🎜 🎜짧은 유효 기간: 🎜 토큰 도난을 방지하기 위해 일반적으로 토큰의 유효 기간은 더 짧게 설정되므로 <code>Refresh Token이 있습니다. 🎜🎜3.2 새로 고침 토큰이란🎜 🎜🎜🎜비즈니스 인터페이스에서 인증에 사용되는 토큰을 액세스 토큰이라고 합니다. 🎜🎜보안상의 이유로 액세스 토큰의 유효 기간은 일반적으로 도난을 방지하기 위해 더 짧게 설정됩니다. 하지만 유효 기간이 너무 짧으면 액세스 토큰이 자주 만료됩니다. 만료된 후에는 어떻게 해야 하나요? 🎜🎜한 가지 방법은 액세스 토큰 새로 고침입니다. 이는 사용자가 새 토큰을 얻기 위해 다시 로그인하는 것이 매우 번거롭습니다.

另外一种办法是：再来一个 Token，一个专门生成 Access Token 的 Token，我们称为 Refresh Token；

• Access Token： 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活；
• Refresh Token： 用来获取 Access Token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 Session 一样处理；

Refresh Token 的认证流程图：



Refresh Token 认证步骤解析：

• 客户端： 输入用户名和密码请求登录校验；

• 服务端： 收到请求，验证用户名与密码；验证成功后，服务端会签发一个 Access Token 和 Refresh Token 并返回给客户端；

• 客户端： 把 Access Token 和 Refresh Token 存储在本地；

• 客户端发送请求： 请求数据时，携带 Access Token 传输给服务端；

• 服务端：

  • 验证 Access Token 有效：正常返回数据
  • 验证 Access Token 过期：拒绝请求

• 客户端 ( Access Token 已过期) ： 则重新传输 Refresh Token 给服务端；

• 服务端 ( Access Token 已过期) ： 验证 Refresh Token ，验证成功后返回新的 Access Token 给客户端；

• 客户端： 重新携带新的 Access Token 请求接口；

3.3 Token 和 Session-Cookie 的区别

Session-Cookie 和 Token 有很多类似的地方，但是 Token 更像是 Session-Cookie 的升级改良版。

• 存储地不同： Session 一般是存储在服务端；Token 是无状态的，一般由前端存储；
• 安全性不同： Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击；
• 支持性不同： Session-Cookie 认证需要靠浏览器的 Cookie 机制实现，如果遇到原生 NativeAPP 时这种机制就不起作用了，或是浏览器的 Cookie 存储功能被禁用，也是无法使用该认证机制实现鉴权的；而 Token 验证机制丰富了客户端类型。

如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

4. JWT（JSON Web Token）鉴权

---

通过第三节，我们知道了 Token 的使用方式以及组成，我们不难发现，服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户基本信息，然后验证 Token 是否有效；


这样每次请求验证都要查询数据库，增加了查库带来的延迟等性能消耗；

那么这时候业界常用的 JWT 就应运而生了！！！

4.1 什么是 JWT

JWT 是 Auth0 提出的通过 对 JSON 进行加密签名来实现授权验证的方案；

就是登录成功后将相关用户信息组成 JSON 对象，然后对这个对象进行某种方式的加密，返回给客户端； 客户端在下次请求时带上这个 Token； 服务端再收到请求时校验 token 合法性，其实也就是在校验请求的合法性。

4.2 JWT 的组成

JWT 由三部分组成： Header 头部、 Payload 负载 和 Signature 签名

它是一个很长的字符串，中间用点（.）分隔成三个部分。列如 ：

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

로그인 후 복사

로그인 후 복사

Header 头部：

在 Header 中通常包含了两部分：

• typ：代表 Token 的类型，这里使用的是 JWT 类型；
• alg：使用的 Hash 算法，例如 HMAC SHA256 或 RSA.

 {
   "alg": "HS256",
   "typ": "JWT"
 }

로그인 후 복사

로그인 후 복사

Payload 负载：

它包含一些声明 Claim (实体的描述，通常是一个 User 信息，还包括一些其他的元数据) ，用来存放实际需要传递的数据，JWT 规定了7个官方字段：

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

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。

 {
   "sub": "1234567890",
   "name": "John Doe",
   "admin": true
 }

로그인 후 복사

로그인 후 복사

Signature 签名

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

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

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

로그인 후 복사

로그인 후 복사

4.3 JWT 的使用方式

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

 Authorization: Bearer <token></token>

로그인 후 복사

4.4 JWT 的认证流程图

其实 JWT 的认证流程与 Token 的认证流程差不多，只是不需要再单独去查询数据库查找用户用户；简要概括如下：



4.5 JWT 的优点

• 不需要在服务端保存会话信息（RESTful API 的原则之一就是无状态），所以易于应用的扩展，即信息不保存在服务端，不会存在 Session 扩展不方便的情况；
• JWT 中的 Payload 负载可以存储常用信息，用于信息交换，有效地使用 JWT，可以降低服务端查询数据库的次数

4.6 JWT 的缺点

• 加密问题： JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
• 到期问题： 由于服务器不保存 Session 状态，因此无法在使用过程中废止某个 Token，或者更改 Token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

4.7 前端常用的 JWT 库推荐

• 使用 express：express-jwt
• 使用 koa：koa-jwt

5. 单点登录（Single Sign On）

---

前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，可以维持一段时间内的登录状态。


但随着企业的发展，一个大型系统里可能包含 n 多子系统，用户在操作不同的系统时，需要多次登录，很麻烦，那么单点登录（SSO) 就可以很好的解决这个问题的，在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。

• 例如登录天猫，淘宝也会自动登录；
• 登录百度贴吧，百度网盘也会自动登录；

5.1 同域下的 SSO（主域名相同）

当百度网站存在两个相同主域名下的贴吧子系统 tieba.baidu.com 和网盘子系统 pan.baidu.com 时，以下为他们实现 SSO 的步骤：

• 客户端： 用户访问某个子系统时（例如 tieba.baidu.com），如果没有登录，则跳转至 SSO 认证中心提供的登录页面进行登录；

• 服务端： 登录认证后，服务端把登录用户的信息存储于 Session 中，并且附加在响应头的 Set-Cookie 字段中，设置 Cookie 的 Domain 为 .baidu.com ；

• 客户端：再次发送请求时，携带主域名 Domain 下的 Cookie 给服务器，此时服务端就可以通过该 Cookie 来验证登录状态了；

其实我们不难发现，这就是我们上面讲的 Session-Cookie 认证 登录方式； 但如果是不同域呢？毕竟不同域之间 Cookie 是不共享的，那怎么办？

5.2 跨域下的 SSO（主域名不同）

저희 일반 쇼핑 사이트인 Tmall(tmall.com)과 Taobao(taobao.com)에서는 시스템 중 하나에만 로그인하면 되고, 다른 시스템은 열면 기본적으로 로그인됩니다. 이것?

그 다음에는 CAS(중앙 인증 서비스) 중앙 인증 서비스가 있으니 먼저 CAS 프로세스에 대해 알아보겠습니다. CAS（Central Authentication Service）中央授权服务，那么我们先主要说下 CAS 的流程；

单点登录下的 CAS 认证流程图：



单点登录下的 CAS 认证步骤详解：

• 客户端： 开始访问系统 A；

• 系统 A： 发现用户未登录，重定向至 CAS 认证服务（sso.com），同时 URL 地址参数携带登录成功后回跳到系统 A 的页面链接（sso.com/login?redir…

• CAS 认证服务： 发现请求 Cookie 中没有携带登录的票据凭证（TGC），所以 CAS 认证服务判定用户处于 未登录 状态，重定向用户页面至 CAS 的登录界面，用户在 CAS 的登录页面上进行登录操作。

• 客户端： 输入用户名密码进行 CAS 系统认证；

• CAS 认证服务： 校验用户信息，并且 生成 TGC 放入自己的 Session 中，同时以 Set-Cookie 形式写入 Domain 为 sso.com 的域下 ；同时生成一个 授权令牌 ST (Service Ticket) ，然后重定向至系统 A 的地址，重定向的地址中包含生成的 ST（重定向地址：www.taobao.com?token=ST-345678）

• 系统 A： 拿着 ST 向 CAS 认证服务发送请求，CAS 认证服务验证票据 (ST) 的有效性。验证成功后，系统 A 知道用户已经在 CAS 登录了（其中的 ST 可以保存到 Cookie 或者本地中），系统 A 服务器使用该票据 (ST) 创建与用户的会话，称为局部会话，返回受保护资源；

到这里客户端就可以跟系统 A 愉快的交往啦 ~

• 客户端： 开始访问系统 B；

• 系统 B： 发现用户未登录，重定向至 SSO 认证服务，并将自己的地址作为参数传递，并附上在 sso.com 域下的 cookie 值是第五步生成的 TGC；

• CAS 认证服务： CAS 认证服务中心发现用户已登录，跳转回系统 B 的地址，并附上票据 (ST) ;

• 系统 B： 拿到票据 (ST)，去 CAS 认证服务验证票据 (ST) 的有效性。验证成功后，客户端也可以跟系统 B 交往了 ~

(PS：脚踏两只船，感觉有点渣呀 ~)

单点登录下需要注意的点：

• 如图中流程所示，我们发现 CAS 认证服务 在签发的 授权令牌 ST 后，直接重定向，这样其实是比较容易容易被窃取，那么我们需要在系统 A 或者系统 B 在向 CAS 验证成功 (如图中的第 14 步和第 11 步) 后，再生成另一个新的验证 Token 返回给客户端保存；

• CAS 一般提供四个接口：

  • /login：登录接口，用于登录到中央授权服务
  • /logout：登出接口，用于从中央授权服务中登出
  • /validate：用于验证用户是否登录中央授权服务
  • /serviceValidate：用于让各个 Service 验证用户是否登录中央授权服务

• CAS 生成的票据：

  • TGT（Ticket Grangting Ticket） ：TGT 是 CAS 为用户签发的 登录票据
  • Single Sign-On Flow에서의 CAS 인증; 차트:
  
  • Single Sign-On의 CAS 인증 단계에 대한 자세한 설명:

클라이언트: 시스템 A에 액세스 시작

---

시스템 A; : 사용자가 로그인되지 않은 채 CAS 인증 서비스(sso.com)로 리디렉션되는 것으로 확인되었습니다. 동시에 URL 주소 매개변수는 로그인 성공 후 시스템 A의 페이지 링크(sso.com/login ?redir…


🎜🎜🎜CAS 인증 서비스: 🎜 요청 쿠키에 로그인 티켓 인증서(TGC)가 없는 것으로 확인되어 CAS 인증 서비스에서 사용자가 로그인 안 됨 상태임을 확인하고 사용자 페이지를 CAS 로그인 인터페이스로 안내하고 사용자가 CAS 로그인 페이지에 로그인했습니다. 🎜🎜🎜🎜🎜클라이언트. : 🎜 CAS 시스템 인증을 위한 사용자 이름과 비밀번호를 입력하세요. 🎜🎜🎜🎜🎜CAS 인증 서비스: 🎜 사용자 정보를 확인하고 TGC를 생성하여 자신의 Session에 입력하고 양식에 작성합니다. Domain이 sso.com인 도메인에 Set-Cookie를 동시에 생성하여 Authorization token ST(Service Ticket)를 생성한 후 해당 주소로 리디렉션합니다. 시스템 A. 리디렉션된 주소에는 생성된 ST(리디렉션 주소: www.taobao.com?token=ST-345678）🎜🎜🎜🎜🎜시스템 A: 🎜 ST를 사용하여 CAS 인증 서비스에 요청을 보내고, CAS 인증 서비스는 티켓(ST)의 유효성을 확인합니다. 성공적인 확인 후 시스템 A는 사용자가 CAS에 로그인했음을 알고(ST는 쿠키에 저장되거나 로컬로 저장될 수 있음) 시스템 A 서버는 티켓(ST)을 사용하여 사용자와 세션을 생성합니다. ;🎜🎜🎜

🎜이 시점에서 클라이언트는 시스템 A와 원만한 관계를 가질 수 있습니다~🎜

🎜🎜🎜클라이언트:🎜 액세스 시스템 B 시작; 🎜🎜🎜🎜🎜시스템 B: 🎜 사용자가 로그인되지 않은 것을 발견하여 SSO 인증 서비스로 리디렉션하고 자신의 주소를 매개 변수로 전달하고 쿠키를 첨부했습니다. sso.com 도메인 아래의 값은 5단계 TGC 생성 🎜🎜🎜🎜🎜CAS 인증 서비스: 🎜 CAS 인증 서비스 센터에서 사용자가 로그인한 것을 확인하고 시스템 B의 주소로 다시 점프하여 티켓을 첨부합니다. (ST); 🎜🎜🎜🎜🎜시스템 B: 🎜 티켓 받기(ST), CAS 인증 서비스로 이동하여 티켓(ST)의 유효성을 확인합니다. 확인이 성공한 후 클라이언트는 시스템 B와도 상호 작용할 수 있습니다~🎜🎜🎜

🎜(PS: 서로 다른 두 가지를 갖는 것은 약간 쓰레기처럼 느껴집니다~)🎜

🎜🎜단일 기호 아래 주의 사항 -on 시점: 🎜🎜
🎜🎜그림의 과정에서와 같이 인증 토큰 ST를 발급한 후 바로 CAS 인증 서비스가 리다이렉트 된 것을 확인하였고, 따라서 실제로 도난당하기가 상대적으로 쉽습니다. 시스템 A 또는 시스템 B가 CAS에 성공적으로 인증된 후 또 다른 새 확인 토큰을 생성하여 클라이언트에 반환하여 저장해야 합니다(그림의 14단계 및 11단계). CAS는 일반적으로 4가지 인터페이스를 제공합니다: 🎜
🎜/login: 중앙 인증 서비스에 로그인하는 데 사용되는 로그인 인터페이스 🎜🎜/logout: 로그아웃 인터페이스, 사용 중앙 인증 서비스🎜🎜/validate에서 로그아웃: 사용자가 중앙 인증 서비스에 로그인했는지 확인하는 데 사용됩니다🎜🎜/serviceValidate: 각 로그아웃을 허용하는 데 사용됩니다. 사용자가 중앙 인증 서비스에 로그인했는지 확인하는 서비스🎜🎜🎜🎜🎜CAS에서 생성된 티켓: 🎜
🎜🎜TGT(Ticket Granting Ticket)🎜: TGT는 로그인 티켓이 발행된 것입니다. 사용자에 대한 CAS가 있고 TGT가 있으면 사용자는 CAS에 성공적으로 로그인했음을 증명할 수 있습니다. 🎜🎜🎜TGC: Ticket Granting Cookie: 🎜 CAS 서버는 TGT를 생성하여 자체 세션에 넣는데, TGC는 이 세션의 고유 식별자(SessionId)를 쿠키 형태로 브라우저 측에 배치하여 사용합니다. CAS 서버에서 사용자의 자격 증명을 명확히 합니다. 🎜🎜🎜ST(서비스 티켓)🎜: ST는 사용자가 서비스에 액세스할 수 있도록 CAS에서 발행하는 티켓입니다. 🎜🎜🎜🎜🎜🎜6.OAuth 2.0🎜🎜🎜🎜 실제로 웹사이트를 탐색할 때 로그인 시 현재 웹사이트의 계정과 비밀번호를 입력하는 것 외에도 제3자를 통해 로그인할 수도 있다는 것을 알게 됩니다. QQ나 WeChat, 그럼 어떻게 🎜OAuth🎜에 대해 이야기해볼까요? 🎜🎜

OAuth 协议又有 1.0 和 2.0 两个版本，2.0 版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。

6.1 什么是 OAuth 2.0？

OAuth 是一个开放标准，允许用户授权第三方网站 (CSDN、思否等) 访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站；

常见的提供 OAuth 认证服务的厂商： 支付宝、QQ、微信、微博

简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（Token），用来代替密码，供第三方应用使用。

令牌与密码的差异：

令牌（Token） 与 密码（Password） 的作用是一样的，都可以进入系统，但是有三点差异。

• 令牌是短期的，到期会自动失效： 用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。

• 令牌可以被数据所有者撤销，会立即失效。

• 令牌有权限范围（scope）： 对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。

OAuth 2.0 对于如何颁发令牌的细节，规定得非常详细。具体来说，一共分成四种授权模式 （Authorization Grant） ，适用于不同的互联网场景。

无论哪个模式都拥有三个必要角色：客户端、授权服务器、资源服务器，有的还有用户（资源拥有者），下面简单介绍下四种授权模式。

6.2 授权码模式

授权码（Authorization Code Grant) 方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

这种方式是最常用的流程，安全性也最高，它适用于那些有后端服务的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

一句话概括：客户端换取授权码，客户端使用授权码换token，客户端使用token访问资源

授权码模式的步骤详解

• 客户端：

  打开网站 A，点击登录按钮，请求 A 服务，A 服务重定向 (重定向地址如下) 至授权服务器 (如QQ、微信授权服务)。

   https://qq.com/oauth/authorize?
     response_type=code&
     client_id=CLIENT_ID&
     redirect_uri=CALLBACK_URL&
     scope=read

  로그인 후 복사

  上面 URL 中，response_type 参数表示要求返回授权码（code），client_id 参数让 B 知道是谁在请求，redirect_uri 参数是 B 接受或拒绝请求后的跳转网址，scope 参数表示要求的授权范围（这里是只读）



• 授权服务器：

  授权服务网站 会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时授权服务网站 就会跳回 redirect_uri 参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

  https://a.com/callback?code=AUTHORIZATION_CODE

  로그인 후 복사

  上面 URL 中，code 参数就是授权码。



• 网站 A 服务器：

  拿到授权码以后，就可以向 授权服务器 (qq.com) 请求令牌，请求地址如下：

   https://qq.com/oauth/token?
    client_id=CLIENT_ID&
    client_secret=CLIENT_SECRET&
    grant_type=authorization_code&
    code=AUTHORIZATION_CODE&
    redirect_uri=CALLBACK_URL

  로그인 후 복사

  上面 URL 中，client_id 参数和 client_secret 参数用来让授权服务器 确认 A 的身份（client_secret 参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code 参数是上一步拿到的授权码，redirect_uri 参数是令牌颁发后的回调网址。



• 授权服务器：

  收到请求以后，验证通过，就会颁发令牌。具体做法是向 redirect_uri 指定的网址，发送一段 JSON 数据。

   {    
     "access_token":"ACCESS_TOKEN",
     "token_type":"bearer",
     "expires_in":2592000,
     "refresh_token":"REFRESH_TOKEN",
     "scope":"read",
     "uid":100101,
     "info":{...}
   }

  로그인 후 복사

  上面 JSON 数据中，access_token 字段就是令牌，A 网站在后端拿到了，然后返回给客户端即可。



6.3 隐藏式模式（Implicit Grant）

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。OAuth2.0 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。

一句话概括：客户端让用户登录授权服务器换token，客户端使用token访问资源。

隐藏式模式的步骤详解

• 客户端：

  打开网站 A，A 网站提供一个链接，要求用户跳转到 授权服务器，授权用户数据给 A 网站使用。如下链接：

   https://qq.com/oauth/authorize?
     response_type=token&
     client_id=CLIENT_ID&
     redirect_uri=CALLBACK_URL&
     scope=read

  로그인 후 복사

  上面 URL 中，response_type参数为token，表示要求直接返回令牌。

• 授权服务器：

  用户跳转到授权服务器，登录后同意给予 A 网站授权。这时，授权服务器就会跳回redirect_uri 参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

   https://a.com/callback#token=ACCESS_TOKEN

  로그인 후 복사

  上面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌。



注意：

• 令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

• 这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

6.4 用户名密码式模式（Password Credentials Grant）

如果你高度信任某个应用，OAuth 2.0 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

一句话概括：用户在客户端提交账号密码换token，客户端使用token访问资源。

密码式模式的步骤详解

• 客户端：

  A 网站要求用户提供 授权服务器(qq.com) 的用户名和密码。拿到以后，A 就直接向 授权服务器 请求令牌。

   https://oauth.b.com/token?
     grant_type=password&
     username=USERNAME&
     password=PASSWORD&
     client_id=CLIENT_ID

  로그인 후 복사

  上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 授权服务器 的用户名和密码。

• 授权服务器：

  授权服务器 验证身份通过后，直接给出令牌。

  注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 网站因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

6.5 客户端模式（Client Credentials Grant）

客户端模式指客户端以自己的名义，而不是以用户的名义，向授权服务器 进行认证。

主要适用于没有前端的命令行应用。

一句话概括：客户端使用自己的标识换token，客户端使用token访问资源。

客户端模式的步骤详解

• 客户端：

  客户端向授权服务器 进行身份认证，并要求一个访问令牌。请求链接地址：

   https://oauth.b.com/token?
     grant_type=client_credentials&
     client_id=CLIENT_ID&
     client_secret=CLIENT_SECRET

  로그인 후 복사

  上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让授权服务器 确认 A 的身份。

• 授权服务器：

  授权服务器 验证通过以后，直接返回令牌。

注意：这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

6.5 授权模式选型

按授权需要的多端情况：

模式	需要前端	需要后端	需要用户响应	需要客户端密钥
授权码模式 Authorization Code	✅	✅	✅	✅
隐式授权模式 Implicit Grant	✅	❌	✅	❌
密码授权模式 Password Grant	✅	✅	✅	✅
客户端授权模式 Client Credentials	❌	✅	❌	✅

클라이언트 유형 및 액세스 토큰 소유자에 따른 분류:



위에서는 주로 OAuth2.0의 기본 로직을 간단하게 설명하고 있습니다. 공식 문서 oauth 또는 rfc 6749 ; 공동로그인

연합로그인은 다중인증을 동시에 포함하는 로그인 서비스를 의미하며, 동시에 3차 인증을 이용한 로그인 서비스로도 이해될 수 있습니다. 확인을 위한 당사자 자격 증명.

일반인의 용어로 말하면:

두 웹사이트 A와 B의 경우, 웹사이트 A에 로그인할 때 웹사이트 B의 계정과 비밀번호를 사용하는 것은 공동 로그인이거나, 웹사이트 B에 로그인할 때 웹사이트 A의 계정과 비밀번호를 사용하는 것은 공동 로그인입니다. 공동 로그인도 됩니다. 이 개념은 실제로 위에서 언급한 OAuth2.0 사용자 이름 비밀번호 모드 인증 방법과 유사합니다. 가장 전형적인 사용 시나리오는 앱에 내장된 H5를 사용하는 시나리오입니다. 사용자가 앱에서 내장된 H5를 입력하면 앱에 로그인한 사용자는 H5의 제한된 리소스에 액세스할 수 있기를 바랍니다. 액세스하려면 로그인이 필요합니다.

---

여기에는 두 가지 주요 아이디어가 있습니다. 하나는 기본적으로 포함된 H5 페이지로 이동할 때 URL 매개변수에 로그인 토큰을 첨부하는 것입니다. 다른 하나는 기본 클라이언트 로그인으로 설정된 프로토콜을 통해 애플리케이션을 적극적으로 가져오는 것입니다. 내의 상태.

7.2 신뢰할 수 있는 로그인이란


신뢰할 수 있는 로그인은 개인 장치와 사용자 간에 설정된 바인딩 관계, 자격 증명은 개인 장치 정보이므로 현재 사용자는 추가 자격 증명을 제공할 필요가 없습니다. 신뢰할 수 있는 로그인은 또한 상대적으로 성숙한 타사 사용자 라이브러리를 사용하여 자격 증명을 확인하고 현재 방문 중인 웹 사이트에 로그인하는 것을 의미합니다. 联合登录 指同时包含多种凭证校验的登录服务，同时，也可以理解为使用第三方凭证进行校验的登录服务。

通俗点讲： 对于两个网站 A 和 B，在登录 A 网站的时候用 B 网站的帐号密码，就是联合登录，或者登录 B 网站的时候使用 A 网站的帐号密码，也是联合登录。

这样的概念其实与上面所讲的 OAuth2.0 的 用户名密码式模式 认证方式类似。

最经典的莫过于 APP 内嵌 H5 的使用场景，当用户从 APP 进入内嵌的 H5 时，我们希望 APP 内已登录的用户能够访问到 H5 内受限的资源，而未登录的用户则需要登录后访问。

这里思路主要有两种，一种是原生跳转内嵌 H5 页面时，将登录态 Token 附加在 URL 参数上，另一种则是内嵌 H5 主动通过与原生客户端制定的协议获取应用内的登录状态。

7.2 什么是信任登录

信任登录 是指所有不需要用户主动参与的登录，例如建立在私有设备与用户之间的绑定关系，凭证就是私有设备的信息，此时不需要用户再提供额外的凭证。信任登录又指用第三方比较成熟的用户库来校验凭证，并登录当前访问的网站。

通俗点讲： 在 A 网站有登录状态的时候，可以直接跳转到 B 网站而不用登录，就是 信任登录

일반인의 용어로 말하면:

웹사이트 A가 로그인되면 로그인 없이 웹사이트 B로 직접 이동할 수 있습니다. 이는 신뢰 로그인입니다.
현재 일반적으로 사용되는 제3자 신뢰할 수 있는 로그인 계정에는 QQ 계정, Taobao 계정, Alipay 계정, Weibo 계정 등이 있습니다.

OAuth 2.0이 실제로 신뢰 로그인의 전형이라는 것을 찾는 것은 어렵지 않습니다. 왜냐하면 OAuth를 사용하여 신뢰 로그인을 실현할 수 있기 때문입니다.

---

8. 고유한 로그인


— 이제 제품 관리자가 다음과 같은 요청을 한다고 가정해 보겠습니다.

사용자는 하나의 장치에만 로그인할 수 있으며 사용자가 반복적으로 로그인하는 것을 금지하고 싶습니다. 훌륭한 프로그래머 물론 우리는 그를 만족시킵니다! !

8.1 고유 로그인이란 무엇입니까?

고유 로그인이란

여러 사람이 동시에 동일한 계정에 로그인하는 것을 금지하는 경우 후자의 로그인 동작으로 인해 전자의 연결이 끊어지는 것을 의미합니다.

간단히 말하면: 계정 A가 컴퓨터 A에 로그인하고 계정 A가 컴퓨터 B를 사용하여 다시 로그인한 후 컴퓨터 A가 페이지를 요청하면 "다시 로그인" 메시지가 표시되고 로그인으로 이동합니다. 페이지

8.2 고유 로그인 흐름 차트



8.3 고유 로그인 단계에 대한 자세한 설명

클라이언트 A의 사용자 작업:

• 계정 번호 입력 로그인 인터페이스 요청;

• 백엔드는 해당 토큰을 생성하여 클라이언트 A에 반환하고 서버에 로그인 상태를 저장합니다.

• 클라이언트 A는 토큰을 저장하고 각 요청은 헤더에 해당 토큰을 전달합니다.
  클라이언트 B의 사용자 작업:

갑자기 사용자가 클라이언트 B에서 로그인 작업을 시작합니다. 단계가 클라이언트 A의 작업과 거의 동일하다는 것을 알 수 있습니다. 토큰, 먼저 로그인 상태를 확인한 다음 해당하는 새 토큰을 생성해야 합니다.

9. 로그인하려면 코드를 스캔하세요

9.1 스캔 코드 로그인이란

---

스캔 코드 로그인은 일반적으로 모바일 앱에서 찾을 수 있습니다. 많은 PC 웹사이트에서는 QR 코드 로그인 기능을 제공합니다. 웹 페이지에서는 계정과 비밀번호를 입력할 필요가 없습니다(예: WeChat). , Taobao, QQ 등) 로그인한 사용자가 QR 코드를 적극적으로 스캔한 후 PC에서 동일한 애플리케이션이 빠르게 로그인할 수 있도록 로그인을 확인하는 방법은 스캔 코드 로그인입니다. . 二维码 ，再确认登录，以使 PC 端的同款应用得以快速登录的方式就是 扫码登录 。

9.2 什么是二维码

二维码 又称二维条码，常见的二维码为 QR Code，QR 全称 Quick Response，是一个近几年来移动设备上超流行的一种编码方式，它比传统的Bar Code条形码能存更多的信息，也能表示更多的数据类型。

通过上面所述，我们不难发现，扫码登录需要三端 (PC端、手机端、服务端) 来进行配合才能达到登录成功的效果；

9.3 扫码登录的认证流程图



9.4 扫码登录的步骤详解 (待扫码阶段、待确认阶段、已确认阶段)

待扫码阶段：

• PC端：

  打开某个网站 (如taobao.com) 或者某个 APP (如微信) 的扫码登录入口；就会携带 PC 端的设备信息向服务端发送一个获取二维码的请求；

• 服务端：

  服务器收到请求后，随机生成一个 UUID 作为二维码 ID，并将 UUID 与 PC 端的设备信息 关联起来存储在 Redis 服务器中，然后返回给 PC 端；同时设置一个过期时间，在过期后，用户登录二维码需要进行刷新重新获取。

• PC 端：

  收到二维码 ID 之后，将二维码 ID 以 二维码的形式 展示，等待移动端扫码。并且此时的 PC 端开始轮询查询二维码状态，直到登录成功。

  如果移动端未扫描，那么一段时间后二维码会自动失效。

已扫码待确认阶段：

• 手机端：

  打开手机端对应已登录的 APP (微信或淘宝等)，开始扫描识别 PC 端展示的二维码；

  移动端扫描二维码后，会自动获取到二维码 ID，并将移动端登录的信息凭证（Token）和二维码 ID 作为参数发送给服务端，此时手机必须是已登录（使用扫描登录的前提是移动端的应用为已登录状态，这样才可以共享登录态）。

• 服务端：

  收到手机端发来的请求后，会将 Token 与二维码 ID 关联，为什么需要关联呢？因为，当我们在使用微信时，移动端退出时，PC 端也应该随之退出登录，这个关联就起到这个作用。然后会生成一个临时 Token，这个 Token 会返回给移动端，一次性 Token 用作确认时的凭证。

已确认阶段：

• 手机端：

  收到确认信息后，点击确认按钮，移动端携带上一步中获取的 临时 Token 发送给服务端校验；

• 服务端：

  服务端校验完成后，会更新二维码状态，并且给 PC 端生成一个 正式的 Token

• 9.2 QR코드란
  QR코드라고도 합니다. 일반적인 QR코드는 Quick Response의 약자입니다. 최근 몇 년 동안 장치에서 매우 널리 사용되는 인코딩 방법으로 기존 바코드보다 더 많은 정보를 저장하고 더 많은 데이터 유형을 표현할 수 있습니다.
  위를 통해 QR 코드를 스캔하여 로그인하려면 세 개의 단말기(PC 단말기, 모바일 단말기, 서버 단말기)가 필요하다는 것을 쉽게 알 수 있습니다. >) 성공적인 로그인을 위해서는 협력이 필요합니다.

9.3 로그인을 위한 QR 코드 스캔을 위한 인증 흐름도



9.4 QR 코드를 스캔하여 로그인하는 단계에 대한 자세한 설명(스캔할 단계, 확정될 단계, 확정된 단계)

---

스캔할 단계:


PC 측:

웹사이트(예: taobao.com)의 스캔 코드 로그인 포털을 엽니다. ) 또는 앱(예: WeChat)이 서비스로 전송됩니다. 클라이언트는 QR 코드를 얻기 위해 요청을 보냅니다.

• 서버:

• 요청을 받은 후; QR 코드 ID로 UUID를 무작위로 생성하고 UUID를 PC 측 장치 정보 코드>와 비교하여 Redis 서버에 저장한 후 동시에 만료되면 PC로 반환합니다. 시간이 설정되면 사용자의 로그인 QR 코드를 새로 고쳐서 다시 가져와야 합니다. <p></p>

PC 단말기:

QR 코드 ID를 받은 후 QR 코드 형식으로 QR 코드 ID를 표시하고 모바일 단말기가 코드를 스캔할 때까지 기다립니다. 그리고 이때 PC는 로그인이 성공할 때까지 QR 코드 상태를 확인하기 위해 폴링을 시작합니다. 🎜🎜모바일 단말기가 스캔되지 않으면 QR 코드는 일정 시간 후에 자동으로 만료됩니다. 🎜🎜🎜🎜🎜 스캔 코드 확인 대기 중: 🎜🎜🎜🎜🎜🎜모바일 버전: 🎜🎜🎜휴대폰에서 🎜로그인🎜에 해당하는 앱(WeChat 또는 Taobao 등)을 열고 스캔 및 식별을 시작하세요. PC 코드에 표시되는 2D QR 코드 🎜🎜모바일 단말기가 QR 코드를 스캔한 후 자동으로 QR 코드 ID를 획득하고 모바일 단말기 로그인 정보 바우처(토큰)와 QR 코드 ID를 매개변수로 서버에 보냅니다. 이때, 휴대폰은 로그인이 되어 있어야 합니다(스캔 로그인을 사용하기 위한 전제조건은 모바일 애플리케이션에 로그인되어 있어야 로그인 상태를 공유할 수 있다는 것입니다). 🎜🎜🎜🎜🎜서버: 🎜🎜🎜휴대폰에서 요청을 받은 후 토큰을 QR 코드 ID와 연결해야 합니다. 왜냐하면 WeChat을 사용하고 모바일 측에서 로그아웃하면 PC 측에서도 로그아웃되어야 하기 때문입니다. 그러면 임시 토큰이 생성되어 모바일 단말기로 반환되며, 일회성 토큰은 확인을 위한 바우처로 사용됩니다. 🎜🎜🎜🎜🎜 확정 단계: 🎜🎜🎜🎜🎜🎜휴대 단말기: 🎜🎜🎜확인 메시지를 받은 후 확인 버튼을 클릭하면, 모바일 단말기에서 획득한 임시 토큰이 휴대됩니다. 이전 단계를 거쳐 서버측 검증으로 보냅니다. 🎜🎜🎜🎜🎜서버측: 🎜🎜🎜서버측 검증이 완료되면 QR 코드 상태가 업데이트되고 공식 토큰 PC 측에 대해 생성됩니다. 후속 PC 측에 서버에 액세스하려면 이 토큰을 보유하기만 하면 됩니다. 🎜🎜🎜🎜🎜PC측: 🎜🎜🎜폴링된 QR코드 상태로 로그인이 되며, 생성된 Token을 획득하고, 로그인이 완료되며, 이후 방문은 Token을 기준으로 완료됩니다. 🎜🎜🎜🎜🎜10. 원클릭 로그인(기본 APP에 적용 가능)🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜10.1 계정과 비밀번호로 로그인🎜🎜🎜🎜🎜모두가 알고 있는 방법은 다음과 같습니다. 에 🎜계정 비밀번호로 로그인 🎜을 사용하세요. 간단하고 조악하며 일반적으로 문제가 없습니다. 🎜🎜🎜단점: 🎜🎜🎜🎜🎜그러나 이 방법을 사용하려면 사용자가 자신의 계정 번호와 비밀번호를 기억해야 합니다. 메모리 비용입니다. 메모리 비용을 줄이기 위해 사용자는 다양한 플랫폼에서 동일한 계정 비밀번호 세트를 사용할 가능성이 높습니다. 보안 측면에서 특정 플랫폼의 계정 비밀번호가 유출되면 해당 사용자가 사용하는 다른 플랫폼에도 영향을 미치게 됩니다. 🎜🎜🎜🎜또한 계정은 개인 신원과 관련이 없기 때문에 동일한 사용자가 여러 개의 다른 계정을 등록할 수 있으며, 이는 악의적인 등록이 발생할 수 있음을 의미합니다. 🎜🎜🎜🎜🎜휴대폰카드 실명제 의무화 해결까지! 🎜🎜

10.2 휴대폰번호 인증코드 로그인

무선인터넷의 발달과 휴대폰카드실명제의 확산으로 휴대폰번호는 계정비밀번호, 휴대폰번호에 비해 특별한 신분증명서가 되었습니다. 악의적인 등록을 방지하기 위해 사용자 신원을 더 잘 확인할 수 있습니다.

그러나 휴대폰 번호를 등록하려면 여전히 휴대폰 번호를 입력하고 SMS 인증 코드를 기다린 후 인증 코드를 입력하고 클릭하여 로그인하는 일련의 지루한 작업이 필요합니다. 전체 과정은 최소 20초 정도 소요되며, 문자 메시지를 받지 못한 경우에는 로그인을 해야 보충할 수 있습니다. 이러한 문제는 잠재적인 사용자 손실로 이어질 수 있습니다.

보안적인 측면에서도 인증코드 유출의 위험이 있습니다. 누군가 귀하의 휴대폰 번호를 알고 인증 코드를 도용한 경우에도 귀하의 계정에 로그인할 수 있습니다.

그래서 원클릭 로그인 작업이 있습니다!

10.3 원클릭 로그인이란

생각해 봅시다. 인증 코드가 왜 필요한가요? 인증번호의 기능은 본인의 휴대폰번호인지 확인하는 것인데, 문자메시지 외에 휴대폰번호를 인증할 수 있는 방법이 있나요?

그래서 우리 주인공은 클릭 한 번으로 로그인이 가능합니다.

SMS 인증코드의 기능은 현재 운영 페이지의 사용자와 휴대폰 번호를 입력한 사용자가 실제로 사용하는 휴대폰 카드 번호를 얻을 수 있는 한 동일인임을 증명하는 것입니다. 현재 휴대폰에서는 추가 작업 없이 이 번호를 사용하여 직접 로그인할 수 있습니다. 작업은 원클릭 로그인입니다.

원클릭 로그인 가능 여부는 운영자가 관련 서비스를 개설하는지 여부에 따라 달라지는데, 이제 운영자가 관련 서비스를 개설함에 따라 우리는 이제 운영자가 제공하는 SDK에 접속하여 관련 서비스를 유료로 이용할 수 있게 되었습니다.

원클릭 로그인 흐름도:



원클릭 로그인 단계에 대한 자세한 설명:

• SDK 초기화: SDK 메소드를 호출하고 platform

• Arouse 인증 페이지: SDK를 호출하여 인증 인터페이스를 호출합니다. SDK는 먼저 운영자에게 요청이 성공한 후 인증으로 이동합니다. 페이지. 인증 페이지에는 사용자 확인을 위한 휴대폰 번호 마스크와 통신사 약관이 표시됩니다.

• 승인에 동의하고 로그인합니다. 사용자는 해당 계약에 동의하고 승인 페이지에서 로그인 버튼을 클릭합니다. SDK는 요청이 성공한 후 토큰을 요청합니다.

• 번호를 얻으려면: 획득한 토큰을 자신의 서버로 보내면 서버는 토큰을 전달하고 통화가 성공하면 교환원의 원클릭 로그인 인터페이스를 호출합니다. 전화번호가 반환됩니다. 서버는 휴대폰 번호를 이용하여 로그인이나 회원가입을 하고, 작업 결과를 클라이언트에 반환하여 원클릭 로그인을 완료합니다.

3대 통신사 개방형 플랫폼:

• 모바일 - 인터넷 기능 개방형 플랫폼

• Telecom - Tianyi 계정 개방형 플랫폼

• China Unicom - WO+ 오픈 플랫폼

  국내 주요 통신사 3사가 각각 독립적인 SDK를 보유하고 있어 호환성 작업이 특히 번거로울 것이다. 원클릭 로그인 솔루션을 사용하려는 경우 제3자를 통해 번호 인증 서비스를 제공할 수 있습니다. 다음 공급업체에는 휴대폰 번호 인증 기능이 있습니다.

  • Alibaba - 번호 인증 서비스
  • Chuanglan - 플래시 인증
  • Aurora - Aurora 인증
  • mob - 2차 인증

참고:

인증 과정에서 사용자는 모바일 네트워크를 켜야 합니다. 기기에 SIM 카드가 삽입되어 있지 않거나, 셀룰러 네트워크가 꺼져 있는 경우, 인증을 완료할 수 없습니다. 따라서 원클릭 로그인이 활성화된 경우에도 기존 로그인 방법과 호환되어야 하며, 실패 시에도 사용자가 정상적으로 로그인 프로세스를 완료할 수 있어야 합니다.

요약

---

위의 10가지 인증 방법을 배우고 이해한 후 간단히 요약해 보겠습니다


• HTTP 기본 인증은 내부 네트워크 또는 보안 요구 사항이 매우 높지 않은 네트워크에 적합합니다. HTTP 基本认证适用于内部网络，或者对安全要求不是很高的网络；
• Session-Cookie 适用于一般中大型的网站（移动端 APP 除外）；
• Token 和 JWT 都适用于市面上大部分的企业型网站，JWT 效能会优于 Token；
• 单点登录 适用于子系统较多的大型企业网站；
• OAuth 2.0适用于需要快速注册用户型的网站；
• 扫码登录 适用于已完成部署了三端的企业；
• 一键登录
세션 쿠키는 일반 중대형 웹사이트에 적합합니다. 모바일 앱 제외)

Token 및 JWT는 시중에 나와 있는 대부분의 기업 웹사이트에 적합하며 JWT 성능은

Single Sign보다 우수합니다. -On은 하위 시스템이 많은 대기업 웹사이트에 적합합니다. <p></p> <code>OAuth 2.0은 사용자를 빠르게 등록해야 하는 웹사이트에 적합합니다.

코드 로그인 스캔 3개의 터미널 배포를 완료한 기존 사용자에게 적합합니다. 원클릭 로그인은 기본 APP에 적합합니다.

🎜🎜🎜이 기사는 https://juejin에서 복사되었습니다. cn/post/7129298214959710244🎜🎜저자 : Master Yi🎜 🎜🎜 (학습 영상 공유 : 🎜웹 프론트엔드🎜)🎜