涉及技术点

OAuth2.0

什么是OAuth2.0？

OAuth 2.0是一个授权（Authorization）框架，它将用户身份验证委托给托管用户帐户的服务提供商，并授权第三方应用程序访问用户帐户。OAuth 2.0为web应用程序、桌面应用程序和移动设备提供授权流。
通过引入授权层，OAuth 2.0将客户机的角色与资源所有者或最终用户分离。如果客户端请求访问由最终用户控制并由资源服务器托管的资源，而不是使用最终用户的凭据访问受保护的资源，则客户端将获得一个访问令牌。在最终用户的批准下，授权服务器将向请求客户端颁发访问令牌。

OAuth2.0中的名词（以微信举例）

resource owner：系统用户（对应微信用户）
client：线网系统（对应某个用微信登录的app）
authorization server：认证中心（对应微信开放平台）
resource server：接口（对应微信api）

OAuth2.0如何工作？

OAuth 2.0 通过使用访问令牌（AccessToken）可以在不泄露用户凭据的情况下访问彼此的数据。

A: client找用户(resource owner)请求授权
B: 用户点确认，认证中心就会给client一个临时授权auth code。
C: client拿着上一步得到的授权code去找authorization server换一个access_token
D: authorization server认证了client的参数，确认后，给client返回access_token
E: client拿access_token去获取信息

sso

帮助网页端建立cookie和session的关联
不同用户在不同client下的token是不一样的）

如何单点登录？

针对任何站点的请求，都将会先重定向到ssoSite去验证用户并检查cookie是否存在。如果存在，则验证过的页面将会发送给浏览器。否则用户将会被重定向到登录页面。浏览器只需存储ssoSite站点的验证cookie

如何单点退出？

1.销毁sso站点全局的会话
2.拿到之前在认证中心注册的子系统集合
3.依次调用子系统的登出方法，销毁局部会话
4.全部销毁之后，跳转到登录页面

OIDC

什么是OIDC？

OpenID Connect（OIDC）是一种开放身份认证( authentication)协议，它对OAuth 2.0进行了配置和扩展，以添加身份层。允许客户端使用OIDC身份验证来确认用户的身份。在OAuth 2.0之上实现OIDC创建了一个单一的框架，该框架承诺在一个单一的、内聚的体系结构中保护API、移动本机应用程序和浏览器应用程序。
OIDC包含OAuth

OIDC与OAuth的区别

OAuth关注的是授权（authorization），即“用户能做什么”；
OpenID侧重的是身份认证（authentication），即“用户是谁”；

JWT

什么是jwt

即Json Web令牌，本质是由.分隔的base64编码字符串，由三部分组成：Header.Payload.VerifySignature

header json 的 base64 编码为令牌第一部分
payload json 的 base64 编码为令牌第二部分
Signature：拼装第一、第二部分编码后的 json 以及用secret 进行签名后为令牌的第三部分

jwt的缺点：由于服务器不保存session状态，无法在使用过程中废止某个token。
Base64Url：这个算法跟 Base64 算法基本类似，但有一些小的不同。JWT 作为一个令牌，有些场合可能会放到 URL（比如 http://api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。

jwt字段含义

iss	Issuer Identifier	authorization server的唯一标识。一般是一个https的url（不包含querystring和fragment部分）
profile	基础资料
sub	Subject Identifier	在iss范围内唯一。client端用户的唯一标识。最长为255个ASCII个字符。（开发者自己定义唯一标识字段）
aud	Audience(s)	标识ID Token的受众。一般是是发起认证授权请求的client_id
exp	Expiration time	过期时间，超过此时间的ID Token会作废不再被验证通过
iat	Issued At Time	JWT构建时间
auth_time	AuthenticationTime	用户完成认证的时间。
nonce		RP发送请求的时候提供的随机字符串，用来减缓重放攻击，也可以来关联ID Token和RP本身的Session信息。
acr	Authentication Context Class Reference	可选。表示一个认证上下文引用值，可以用来标识认证上下文类。
amr	Authentication Methods References	可选。表示一组认证方法。
azp	Authorized party	可选。结合aud使用。只有在被认证的一方和受众（aud）不一致时才使用此值，一般情况下很少使用。

jwt签名算法

HS256：使用同一个「secret_key」进行签名与验证（对称加密）
RS256：使用 RSA 私钥进行签名，使用 RSA 公钥进行验证
ES256 ：私钥签名，公钥验证，签名长度相对短

RSA

签名与加密的区别？
签名：保证数据是从自己发出去的。发送者私钥加密，接收者公钥解密。
加密：保证接收者能够看到数据。发送者公钥加密，接受者私钥解密。
签名与证书？
在验证签名时，需要用公钥对签名解密。为保证公钥不是伪造的，需要对公钥进行签名，所以证书又叫【公钥的数字签名】，对公钥签名需要找可信的第三方即【证书颁布机构 CA】。
证书怎么工作？
1.CA 会将：证书的颁布机构、有效期、公钥、持有者(subject)等信息用 CA 的私钥进行签名，将签名结果和这些信息放在一起，组成【数字证书】，发给申请者（即认证服务器）
2.资源服务器需要安装同样的【数字证书】，用CA的公钥进行验证

怎么导入？

当API和授权服务器托管在不同的应用程序中时，可以使用标准OpenID Connect discovery自动导入非对称签名密钥

怎么存储？
对于IIS应用程序，建议将证书存储在计算机存储中。
怎么定期更新？

AccessToken

什么是AccessToken

用来访问受保护资源的凭证，在客户端和资源服务器之间交互。
除了用户ID（“sub”）之外，不应包含任何关于用户本身的信息，不要试图从中解析信息。
支持通过（“scope”）对权限进行判定。
格式可以是jwt可以是随机字符串

jwt格式示例

eyJhbGciOiJSUzI1NiIsImtpZCI6IjI1WTZSOC0ySFI3TTJORC04VjlYVUxUR0tCV0ZJMUZGX1EyQ01WS0kiLCJ0eXAiOiJhdCtqd3QifQ.eyJzdWIiOiIxIiwic29tZSBjbGFpbSI6InNvbWUgdmFsdWUiLCJvaV9wcnN0IjoicG9zdG1hbiIsIm9pX2F1X2lkIjoiOTVlM2M2ZTMtMzJhZS00MTQ1LTgyZWItNWNmZmExMTE5YjI3IiwiY2xpZW50X2lkIjoicG9zdG1hbiIsIm9pX3Rrbl9pZCI6IjAzZmY0ZjExLWM2MDgtNDdhZS04MTllLWMwOTRjNmJlYTRjMyIsInNjb3BlIjoiYXBpIG9wZW5pZCBvZmZsaW5lX2FjY2VzcyIsImV4cCI6MTY0NjM4MzQ2MSwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6NTAwMS8iLCJpYXQiOjE2NDYzNzk4NjF9.fxiboJ_Wzh8SPuI1uKG1akqJiKBWlPzqhXFiK4E1eNIqdqmYrasqRQfMLeZ7QSxhw5gSgcDYSS7yMKSjb5a3Xm3--i-BHz14bLpofZz2oDuzd0BGtIdF_970oZ-XgKTvPu63GLjkuImBMjxDcuRcBoHdkDyWgN983-FOVe2cp-Ug6mRDicAzJ82LcB1Rqx9Oa4Uk_rlSyKeQPzC8lTZswY-wNzfl8yBsrdwUlmrllKFHHajLbeZuNjLA6I1GahwRmBvcD36awb2PNfuTb6M290V5Hu8QvZSx7Qp3DD6oubOU9_zU_D1JFIyqQB3PrzJY0RP7nI-V5lreVopsCzuEEw.eyJqdGkiOiIzWUJ5eWZ2TDB4b01QNXdwTXVsZ0wiLCJzdWIiOiI2MDE5NDI5NjgwMWRjN2JjMmExYjI3MzUiLCJpYXQiOjE2MTI0NDQ4NzEsImV4cCI6MTYxMzY1NDQ3MSwic2NvcGUiOiJvcGVuaWQgZW1haWwgbWVzc2FnZSIsImlzcyI6Imh0dHBzOi8vc3RlYW0tdGFsay5hdXRoaW5nLmNuL29pZGMiLCJhdWQiOiI2MDE5M2M2MTBmOTExN2U3Y2IwNDkxNTkifQ.cYyZ6buwAjp7DzrYQEhvz5rvUBhkv_s8xzuv2JHgzYx0jbqqsWrA_-gufLTFGmNkZkZwPnF6ktjvPHFT-1iJfWGRruOOMV9QKPhk0S5L2eedtbKJU6XIEkl3F9KbOFwYM53v3E7_VC8RBj5IKqEY0qd4mW36C9VbS695wZlvMYnmXhIopYsd5c83i39fLBF8vEBZE1Rq6tqTQTbHAasR2eUz1LnOqxNp2NNkV2dzlcNIksSDbEGjTNkWceeTWBRtFMi_o9EWaHExdm5574jQ-ei5zE4L7x-zfp9iAe8neuAgTsqXOa6RJswhyn53cW4DwWg_g26lHJZXQvv_RHZRlQ

解析后的内容

{"sub": "411403199112166017","userid": "6177758f581828d2f74e0f88",//用户id"oi_prst": "postman","oi_au_id": "62209b139a3aeefcd74fdff5","client_id": "postman","oi_tkn_id": "62209b169a3aeefcd74fdff8","scope": "api openid offline_access","exp": 1646307622,"iss": "https://localhost:4321/","iat": 1646304022
}

使用示例

request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);

如何存储access_token?

放在内存中，减少对数据库的网络请求

Redis（支持，兼容旧认证方式）
jwt（支持，新认证方式）

如何验证access_token（id_token）?

1.使用Bearer Token将access_token传递给资源服务器

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer access_token

2.解码JWT token
授权服务器将拥有一个用于签名令牌的私钥，资源服务器将从授权服务器元数据中获取公钥，以用于验证令牌。
3.判断过期时间未超期
jwt签名算法：RS256
（自己的服务端给自己客户端发token）
todo
(接入用户)
自己应用发code（需要密码）
一个应用跳转到其他应用（）

ID Token

ID Token是一个安全令牌，适用于认证场景。例如，有第三方应用需要使用我司系统登录，登录后，我司会返回ID Token给第三应用。
由授权服务器提供的**用户信息（由一组Cliams构成以及其他辅助的Cliams）**的JWT格式的数据结构。用户信息可以包括用户名、邮箱、头像等信息。

ID Token的主要构成部分如下
（同原login接口返回数据格式）

{"sub": "411403199112166017","username": "411403199112166017",//用户名"_id": "6177758f581828d2f74e0f88",//用户id"email": "999@qq.com",//"RoleType": "2",//"PhoneNumber": "18647031037",//"RealName": "线网管理员",//"oi_au_id": "62209b139a3aeefcd74fdff5","azp": "postman","at_hash": "1S8w9jfV58B9XLJcRzrHiQ","oi_tkn_id": "62209b169a3aeefcd74fdffa","aud": "postman","exp": 1646305222,"iss": "https://localhost:4321/","iat": 1646304022
}

RefreshToken

什么是refresh_token?

用于获取新的 AccessToken,在客户端和授权服务器之间交互。这样可以缩短 AccessToken 的过期时间保证安全，同时又不会因为频繁过期重新要求用户登录。
在初次认证时，Refresh Token 会和 AccessToken、IdToken 一起返回。
应用携带 Refresh Token 向 Token 端点发起请求时，认证服务器每次都会返回相同的 Refresh Token 和新的 AccessToken、IdToken，直到 Refresh Token 过期。

refresh token需要过期时间么？

客户端需要保存token和refresh token，以便下一次访问能继续。如果客户端是浏览器，那么两个token都需要设置过期时间；但是可以设置得长一点，可以以天为单位（例如7天、15天）；如果客户端是一个服务器，那么refresh token可以永久有效，直到下一次登录，refresh token本身被更新为止。

Flow

Authorization Code Flow

特点

access_token 和refresh_token
redirection-based flow
有用户参与

适合client具备后端服务器的场景。要求client必须能够安全存储密钥,用于后续使用auth code换access token，需要通过浏览器与终端用户交互完成认证授权。通过浏览器重定向将auth code发送到authorization server，换取access token

步骤
1）Authorization Code Request
当用户（Resource Owner）访问第三方应用（Client）的时候，第三方应用会把用户带到认证服务器（Authorization Server）上去，主要请求的是 /authorize API，其中的请求方式如下所示。

https://login.authorization-server.com/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Fexample-client.com%2Fcallback%2F&scope=read&state=xcoiv98CoolShell3kch

其中：

client_id：【必选】为第三方应用的App ID
response_type=code【必选】告诉认证服务器，我要走Authorization Code Flow。
redirect_uri【必选】跳转回第三方应用的URL
scope【必选】相关的权限，OIDC的请求必须包含值为“openid”的scope的参数。
state 【推荐】是一个随机的字符串，主要用于防CSRF攻击。

2）对请求参数做严格的验证
当Authorization Server收到这个URL请求后，其会通过 client_id来检查 redirect_uri和 scope是否合法，如果合法，则弹出一个页面，让用户（EU）授权（如果用户没有登录，则先让用户登录，登录完成后，出现授权访问页面）。

3）重定向到RP指定的回调地址
当用户授权同意访问以后，Authorization Server 会跳转回 Client ，并且把 Authorization Code和state传过去。
一个access_token的示例：

  HTTP/1.1 302 FoundLocation: https://client.example.org/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj

state 的值也和第 1）步的 state一样。

4）Exchange Code For Access Token(ID Token)
接下来，Client 就可以使用 Authorization Code 获得 Access Token。其需要向 Authorization Server 发出如下请求。

POST /oauth/token HTTP/1.1
Host: authorization-server.comcode=Yzk5ZDczMzRlNDEwYlrEqdFSBzjqfTG
&grant_type=code
&redirect_uri=https%3A%2F%2Fexample-client.com%2Fcallback%2F
&client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&client_secret=JqQX2PNo9bpM0uEihUPzyrh

5）如果没什么问题，授权服务器使用私钥签发 JWT 形式的token

{"access_token": "iJKV1QiLCJhbGciOiJSUzI1NiI",//访问请求令牌"refresh_token": "1KaPlrEqdFSBzjqfTGAMxZGU",//用于刷新 access_token"token_type": "bearer","expires": 3600,"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciO.eyJhdWQiOiIyZDRkM..." //JWT格式的ID Token
}

6）用 Access Token 请求用户的资源

GET /v1/user/pictures
Host: https://example.resource.comAuthorization: Bearer iJKV1QiLCJhbGciOiJSUzI1NiI

Client Credentials Flow

特点

不支持refresh token
没有用户的参与，app_key和app_secret基本等价于账号和密码

Client Credentials 模式用于进行服务器对服务器间的授权（M2M 授权），期间没有用户的参与。你需要创建编程访问账号，并将 AK、SK 密钥对交给你的资源调用方。

Implicit Flow

特点

即client-side模式，是OAuth2.0认证的一种模式，又称User-Agent Flow；
直接通过带有“#”符号的重定向URL返回access_token,不支持refresh_token
最终的access_token会存储在客户端中（browser/app）

在隐式模式中，应用不需要使用 code 换 token，无需请求 /token 端点，AccessToken 和 IdToken 会直接从认证端点返回。适用于需要通过客户端访问的方式，例如需要通过浏览器的javascript代码，或者电脑/移动终端上的客户端访问时。
什么是client-side模式？

在用户硬盘上 —— 而非通常存储数据的服务器 —— 存储数据
web app 离线可用

如果用户成功登录并授权，则会跳转到指定的回调地址，并在URL后加“#”号，带上Access Token以及expires_in等参数。如果请求参数中传入了state，这里会带上原始的state值。如果redirect_uri地址后已经有“#”号，则加“&”号，带上相应的返回参数。如：
PC网站：http://graph.qq.com/demo/index.jsp?#access_token=FE04CCE2&expires_in=7776000&state=test
WAP网站：http://open.z.qq.com/demo/index.jsp?#access_token=FE04CCE2&expires_in=7776000&state=test
说明：expires_in是该access token的有效期，单位为秒。

Tips：

可通过js方法：window.location.hash来获取URL中#后的参数值。
建议用js设置cookie存储token。

Resource Owner Password Credentials Grant

不需要重定向跳转
需要用户把账号和密码给client，client拿着去认证中心换token
一般常见于自家应用使用自家的资源

适用于你既掌握应用程序又掌握应用所需资源的场景。密码模式要求应用能够安全存储密钥，并且能够被信任地存储资源所有者的账密。一般常见于自家应用使用自家的资源。密码模式不需要重定向跳转，只需要携带用户账密访问 Token 端点。

根据Refresh Token请求AccessToken

用户刷新access_token用的token。超时时间比较久。设定超时为30天，失效后需要用户重新授权

appid: client id,
grant_type: refresh_token(固定)
refresh_token: 上一步获取到的token

如何选择合适的授权模式

应用类型	授权模式
有后端场景	授权码模式
SPA（单页应用程序），无后端	隐式模式
服务器之间	Client Credentials

通过上图敲定pc端和web端的授权方式：

授权模式	Access Token	Id Token	应用
授权码模式	✅	✅	pc端 web端
隐式模式	✅	✅

密码模式	✅	✅

Client Credentials 模式	✅	❌

Request params

Scope

scope 名称	对应信息
username	username
address	address
email	email，email_verified
phone	phone_number, phone_number_verified
profile	birthdate，family_name，gender，given_name，locale，middle_name，name，nickname，picture，preferred_username，profile，updated_at，website，zoneinfo
offline_access	如果存在此参数，token 接口会返回 refresh_token 字段
roles	对应 role 信息，用户的角色列表
unionid	用户的 unionid 字段
openid	用户的 openid 字段
external_id	用户在原有系统的用户 ID
extended_fields	用户的扩展字段信息，内容为一个对象，key 为扩展字段名，value 为扩展字段值

max_age

指定自最终用户上次被OP主动验证以来允许的已用时间（秒）。如果已用时间大于此值，OP必须尝试主动重新验证最终用户.
当使用max_age时，返回的IDToken必须包含身份验证时间

response-type

“response_type” value	Flow
code	Authorization Code Flow（授权码模式）
id_token	Implicit Flow（隐式模式）
id_token token	Implicit Flow（隐式模式）
code id_token	Hybrid Flow（混合模式）
code token	Hybrid Flow（混合模式）
code id_token token	Hybrid Flow（混合模式）

prompt

用于指定授权服务器是否提示最终用户重新验证和同意

none	授权服务器不得显示任何身份验证或同意用户界面页面
login	授权服务器应提示最终用户重新验证。如果无法重新验证最终用户，则必须返回错误，通常需要登录
consent	授权服务器应在将信息返回给客户端之前提示最终用户同意。如果无法获得同意，则必须返回错误，通常需要获得同意。
select_account	授权服务器应提示最终用户选择用户帐户

OpenIddict开源框架简介

简介

OpenIddict 的目的是提供一个通用的解决方案，在任何 ASP.NET Core 2.1、3.1 和 5.0 应用程序中实现 OpenID Connect 服务器和令牌验证，从 OpenIddict 3.0 开始，任何使用 Microsoft.Owin 的 ASP.NET 4.x 应用程序也是如此。
OpenIddict 完全支持code/implicit/hybrid flows（代码/隐式/混合流），client credentials/resource owner password grants（客户端凭证/资源所有者密码授予）和设备授权流。您也可以创建自己的自定义授权类型。
OpenIddict 原生支持 Entity Framework Core、Entity Framework 6 和 MongoDB 开箱即用，但你也可以提供自己的存储。

使用OIDC的企业
Google的账号认证授权体系
Microsoft的账号体系也部署了OIDC

表结构

客户端

zx_sys_partner
openiddict.applications

access_token

openiddict.tokens（因为是框架自动下发的，无法捕捉到）

authorization_code

zx_sys_oauth2_authorization_code

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rFxuPP8S-1655342884373)(https://cdn.nlark.com/yuque/0/2022/jpeg/938970/1646730044074-60903575-3d17-4511-b5fb-4f6eb9ee0ff6.jpeg)]

二次开发文档

接口文档

问题记录

测试环境和生产环境用同一个证书的话，jwt验证都会通过

参考文档

OAuth 2.0标准：https://datatracker.ietf.org/doc/html/rfc6749#section-4.4
identityserver:http://docs.identityserver.io/en/latest/intro/big_picture.html
The Simplest Guide To OAuth 2.0：https://darutk.medium.com/the-simplest-guide-to-oauth-2-0-8c71bd9a15bb
AccessToken Vs ID Token Vs Refresh Token：https://www.c-sharpcorner.com/article/accesstoken-vs-id-token-vs-refresh-token-what-whywhen/
choose flow:https://docs.authing.cn/v2/concepts/oidc/choose-flow.html
choose flow2：https://www.cnblogs.com/woshimrf/p/OAuth2.html
openid connect core 1.0:https://openid.net/specs/openid-connect-core-1_0.html
开放文档参考：https://docs.authing.cn/v2/federation/oidc/authorization-code/?step=0
开放文档参考：http://monetization-docs.xg.tagtic.cn/#/login
openiddict教程：https://www.cnblogs.com/liyouming/p/15772403.html
sign:https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/
Signing keys, certificates and client secrets confusion：https://stackoverflow.com/questions/50862755/signing-keys-certificates-and-client-secrets-confusion
跨域：
https://juejin.cn/post/6844903862743089165
https://mp.weixin.qq.com/s/5iiISiDm4pDQmRjf4Q4x0A

单点登录涉及的技术点相关推荐

企业门户应用整合中单点登录(SSO)的技术实现与应用
企业门户应用整合中单点登录(SSO)的技术实现与应用相关专题: 电子应用时间:2009-07-27 09:56来源: icbuy亿芯网 1 引言企业在信息化建设过程中,由于经常采用逐步信息化的 ...
java单点登录跨域_深入浅出让你理解跨域与SSO单点登录原理与技术
原标题:深入浅出让你理解跨域与SSO单点登录原理与技术一:SSO体系结构 SSO SSO英文全称Single Sign On,单点登录.SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互 ...
单点登录 cas 设置回调地址_单点登录落地实现技术有哪些，有哪些流行的登录方案搭配？...
实现单点登录说到底就是要解决如何产生和存储那个信任,再就是其他系统如何验证这个信任的有效性,因此要点也就以下两个:1.存储信任 :2.服务器生产~验证信任 : 3.拿到服务器再次验证. 单点登录的常 ...
通达OA系统对接单点登录标准SaaS技术服务说明
1 标准技术服务项目标准业务类型服务说明服务项目预估工期 (人/天) HR接口对接 (人员组织同步) 支持HR接口信息对接(因钉钉服务限制,做钉钉接口需要单独购买服务器进行部署) • 支持平 ...
asp 退出登录修改cookie能进入后台_深入浅出让你理解跨域与SSO单点登录原理与技术...
一:SSO体系结构 SSO SSO英文全称Single Sign On,单点登录.SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统.它包括可以将这次主要的登录映射到其他应用 ...
深入理解跨域SSO单点登录原理与技术
文章目录 1 SSO体系结构 1.1 SSO 1.2 体系结构 1.3 Token(令牌) 1.4 同域SSO原理分析 token的生成 token过期移除认证流程 1.5 跨域SSO原理分析分析 ...
SSO模型及单点登录SSO技术选型
一.多系统的复杂性 web系统早已从久远的单系统发展成为如今由多系统组成的应用群,面对如此众多的系统,用户难道要一个一个登录.然后一个一个注销吗?就像下图描述的这样 web系统由单系统发展成多系统组成 ...
[转]单点登录原理与简单实现
一.单系统登录机制 1.http无状态协议 web应用采用browser/server架构,http作为通信协议.http是无状态协议,浏览器的每一次请求,服务器会独立处理,不与之前或之后的请求产生关 ...
爆破专栏丨Spring Security系列教程之实现CAS单点登录上篇-概述
作者:千锋一一哥前言从本章节开始,一一哥会给各位讲解一个很常见也很重要的知识点,就是单点登录!现在的大型分布式项目,基本都会考虑实现单点登录,而且现在网上也有很多单点登录的实现方案.开源项目,但 ...

单点登录涉及的技术点