多种认证、授权模型的比较
本文主要列举在如今前后端分离、手机App大行其道的现状下，用户认证、授权的几种做法及对比。本文假设你已经理解了各种认证模式的具体细节。
OAuth2.0的几种模式
|
Grant type
|
Client owner
|
User context?
|
Client type
|
App type
|
|---|
|
Authorization Code
|
Third-party
|
Y
|
confidential
|
Web app
|
|
Authorization Code, without client secret
|
Third-party
|
Y
|
public
|
User-agent app
|
|
Authorization Code, without client secret, with PKCE
|
Third-party
|
Y
|
public
|
Native app
|
|
OAuth2 Implicit(deprecated)
|
Third-party
|
Y
|
public
|
User-agent app, Native app
|
|
Password
|
First-party
|
Y
|
both
|
Web app, User-agent app, Native app
|
|
Client Credentials
|
Third-party
|
N
|
confidential
|
Web app
|
-
User: 自然人。
-
Client: 索要Authorization Code和Access Token的程序。
-
First-party: 第一方client，即client开发者/厂商和Resource Server是同一个人/厂商。
-
Third-party: 第三方client，即client开发者/厂商和Resource Server不是同一个人/厂商。OAuth 2.0主要解决的是第三方client的授权问题。
-
Y: 代表被授权的资源是和当前User相关的。
-
N: 代表被授权的资源是和Client相关的。
-
Confidential: 这类Client和Authorization Server/Resource Server的通信是秘密进行的。
-
Public: 这类Client和Authorization Server/Resource Server的通信是公开进行的。
-
web app: 这类App的代码在服务器上执行，用户通过User-Agent（浏览器）下载App渲染的HTML页面，并与之交互。比如，传统的MVC应用。
-
user-agent app: 这类App的代码是直接下载到User-Agent（浏览器）里执行的。比如，前后端分离App、SPA。
-
native app: 这类App安装在用户的设备上，可以认为这类App内部存储的credential信息是有可能被提取的。比如，手机App、桌面App。
仅做认证的模式
|
Mode
|
Client belong
|
User Context
|
App type
|
|---|
|
Session
|
First-party
|
Y
|
Web app
|
|
SSO
|
First-party
|
Y
|
Web app
|
|
JWT
|
First-party
|
Y
|
Web app, User-agent app, Native app
|
-
用户会话信息不通过Cookie携带，而是放在Header里，这个信息我们叫做Token。
-
Token里包含了加密的、不可篡改的当前登录用户的信息，SESSIONID只是一个代号，是没有这个信息的。
-
服务端可以做到无状态，因为用户信息在Token里已经存在，再也不需要维护Session了。
来源：https://chanjarster.github.io/
原创声明
本站部分文章基于互联网的整理，我们会把真正“有用/优质”的文章整理提供给各位开发者。本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
服务热线 19970861797
