mirror of
https://gitee.com/dromara/sa-token.git
synced 2025-09-23 04:23:36 +08:00
优化文档
This commit is contained in:
@@ -38,7 +38,7 @@
|
|||||||
- **分布式会话** —— 提供jwt集成、共享数据中心两种分布式会话方案
|
- **分布式会话** —— 提供jwt集成、共享数据中心两种分布式会话方案
|
||||||
- **微服务网关鉴权** —— 适配Gateway、ShenYu、Zuul等常见网关的路由拦截认证
|
- **微服务网关鉴权** —— 适配Gateway、ShenYu、Zuul等常见网关的路由拦截认证
|
||||||
- **单点登录** —— 内置三种单点登录模式:无论是否跨域、是否共享Redis,都可以搞定
|
- **单点登录** —— 内置三种单点登录模式:无论是否跨域、是否共享Redis,都可以搞定
|
||||||
- **OAuth2.0认证** —— 基于RFC-6749标准编写,OAuth2.0标准流程的授权认证,支持openid模式
|
- **OAuth2.0认证** —— 轻松搭建 OAuth2.0 服务,支持openid模式
|
||||||
- **二级认证** —— 在已登录的基础上再次认证,保证安全性
|
- **二级认证** —— 在已登录的基础上再次认证,保证安全性
|
||||||
- **Basic认证** —— 一行代码接入 Http Basic 认证
|
- **Basic认证** —— 一行代码接入 Http Basic 认证
|
||||||
- **独立Redis** —— 将权限缓存与业务缓存分离
|
- **独立Redis** —— 将权限缓存与业务缓存分离
|
||||||
|
@@ -96,7 +96,7 @@ StpUtil.switchTo(10044); // 将当前会话身份临时切换为其它账号
|
|||||||
- **分布式会话** —— 提供jwt集成、共享数据中心两种分布式会话方案
|
- **分布式会话** —— 提供jwt集成、共享数据中心两种分布式会话方案
|
||||||
- **微服务网关鉴权** —— 适配Gateway、ShenYu、Zuul等常见网关的路由拦截认证
|
- **微服务网关鉴权** —— 适配Gateway、ShenYu、Zuul等常见网关的路由拦截认证
|
||||||
- **单点登录** —— 内置三种单点登录模式:无论是否跨域、是否共享Redis,都可以搞定
|
- **单点登录** —— 内置三种单点登录模式:无论是否跨域、是否共享Redis,都可以搞定
|
||||||
- **OAuth2.0认证** —— 基于RFC-6749标准编写,OAuth2.0标准流程的授权认证,支持openid模式
|
- **OAuth2.0认证** —— 轻松搭建 OAuth2.0 服务,支持openid模式
|
||||||
- **二级认证** —— 在已登录的基础上再次认证,保证安全性
|
- **二级认证** —— 在已登录的基础上再次认证,保证安全性
|
||||||
- **Basic认证** —— 一行代码接入 Http Basic 认证
|
- **Basic认证** —— 一行代码接入 Http Basic 认证
|
||||||
- **独立Redis** —— 将权限缓存与业务缓存分离
|
- **独立Redis** —— 将权限缓存与业务缓存分离
|
||||||
|
@@ -14,7 +14,7 @@
|
|||||||
|
|
||||||
解决这个问题的关键就在于 `SaTokenContext` 接口,此接口的作用是屏蔽掉不同 Web 框架之间的差异,提供统一的调用API:
|
解决这个问题的关键就在于 `SaTokenContext` 接口,此接口的作用是屏蔽掉不同 Web 框架之间的差异,提供统一的调用API:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
|
||||||
SaTokenContext只是一个接口,没有工作能力,这也就意味着 SaTokenContext 接口的实现是必须的。
|
SaTokenContext只是一个接口,没有工作能力,这也就意味着 SaTokenContext 接口的实现是必须的。
|
||||||
|
@@ -11,15 +11,13 @@
|
|||||||
[OAuth2.0 简单解释](https://www.ruanyifeng.com/blog/2019/04/oauth_design.html)
|
[OAuth2.0 简单解释](https://www.ruanyifeng.com/blog/2019/04/oauth_design.html)
|
||||||
<!-- 、[OAuth2.0 的四种方式](http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html) -->
|
<!-- 、[OAuth2.0 的四种方式](http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html) -->
|
||||||
|
|
||||||
<!-- Sa-OAuth2 模块基于 [RFC-6749 标准](https://tools.ietf.org/html/rfc6749) 编写,通过Sa-OAuth2你可以非常轻松的实现系统的OAuth2.0授权认证 -->
|
|
||||||
|
|
||||||
如果你还不知道你的项目应该选择 SSO 还是 OAuth2.0,可以参考这篇:[技术选型:[ 单点登录 ] VS [ OAuth2.0 ]](/fun/sso-vs-oauth2)
|
如果你还不知道你的项目应该选择 SSO 还是 OAuth2.0,可以参考这篇:[技术选型:[ 单点登录 ] VS [ OAuth2.0 ]](/fun/sso-vs-oauth2)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### OAuth2.0 四种模式
|
### OAuth2.0 四种模式
|
||||||
|
|
||||||
Sa-OAuth2 模块基于 [RFC-6749 标准](https://tools.ietf.org/html/rfc6749) 编写,基于不同的使用场景,OAuth2.0设计了四种模式:
|
基于不同的使用场景,OAuth2.0设计了四种模式:
|
||||||
|
|
||||||
1. 授权码(Authorization Code):OAuth2.0标准授权步骤,Server端向Client端下放Code码,Client端再用Code码换取授权Token
|
1. 授权码(Authorization Code):OAuth2.0标准授权步骤,Server端向Client端下放Code码,Client端再用Code码换取授权Token
|
||||||
2. 隐藏式(Implicit):无法使用授权码模式时的备用选择,Server端使用URL重定向方式直接将Token下放到Client端页面
|
2. 隐藏式(Implicit):无法使用授权码模式时的备用选择,Server端使用URL重定向方式直接将Token下放到Client端页面
|
||||||
@@ -28,7 +26,7 @@ Sa-OAuth2 模块基于 [RFC-6749 标准](https://tools.ietf.org/html/rfc6749)
|
|||||||
|
|
||||||

|

|
||||||
|
|
||||||
接下来我们将通过简单示例演示如何在Sa-OAuth2中完成这四种模式的对接: [搭建OAuth2-Server](/oauth2/oauth2-server)
|
接下来我们将通过简单示例演示如何在 Sa-OAuth2 中完成这四种模式的对接: [搭建OAuth2-Server](/oauth2/oauth2-server)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@@ -123,7 +123,7 @@
|
|||||||
</div>
|
</div>
|
||||||
<div class="feature">
|
<div class="feature">
|
||||||
<h2>🍂 OAuth2.0</h2>
|
<h2>🍂 OAuth2.0</h2>
|
||||||
<p>基于 RFC-6749 标准编写,轻松搭建 OAuth2.0 认证中心,支持四种授权模式,支持openid机制</p>
|
<p>轻松搭建 OAuth2.0 认证中心,支持四种授权模式,支持 openid 授权机制,支持二次扩展开发</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="feature">
|
<div class="feature">
|
||||||
<h2>💦️ 微服务支持</h2>
|
<h2>💦️ 微服务支持</h2>
|
||||||
|
Reference in New Issue
Block a user