oauth

问题： I'm really trying to understand the difference between OpenID and OAuth? 我真的想了解OpenID和OAuth之间的区别吗？ Maybe they're two totally separate things? 也许他们是两个完全不同的东西？ 解决方案： 参考一： https://stackoom.com/question/4Yml/OpenID和OAuth有什么区别 参考二： https://oldbug.net/q/4Yml/What-s-the-difference-between-OpenID-and-OAuth 来源： oschina 链接： https://my.oschina.net/u/4438370/blog/4318166

上一篇文章( https://www.cnblogs.com/meowv/p/12924859.html )再次把Swagger的使用进行了讲解，完成了对Swagger的分组、描述和开启小绿锁以进行身份的认证授权，那么本篇就来说说身份认证授权。 开始之前先搞清楚几个概念，请注意认证与授权是不同的意思，简单理解：认证，是证明你的身份，你有账号密码，你可以登录进我们的系统，说明你认证成功了；授权，即权限，分配给用户某一权限标识，用户得到什么什么权限，才能使用系统的某一功能，就是授权。 身份认证可以有很多种方式，可以创建一个用户表，使用账号密码，也可以接入第三方平台，在这里我接入GitHub进行身份认证。当然你可以选择其他方式(如：QQ、微信、微博等)，可以自己扩展。 打开GitHub，进入开发者设置界面( https://github.com/settings/developers )，我们新建一个 oAuth App。 如图所示，我们将要用到敏感数据放在 appsettings.json 中 { ... "Github": { "UserId": 13010050, "ClientID": "5956811a5d04337ec2ca", "ClientSecret": "8fc1062c39728a8c2a47ba445dd45165063edd92", "RedirectUri":

@[toc] 跨域这个问题松哥之前写过文章，但是最近收到小伙伴们的一些问题，让我发现之前的总结不够全面，因此打算再写一篇文章，来和大家分享一下 Spring Boot 中的跨域问题。 这次我把 Spring Boot 中的跨域问题分为了三个场景： 普通跨域 Spring Security 跨域 OAuth2 跨域 分为三种并非多此一举，主要是因为这三种场景的配置都不太一样，而这三种场景又都是非常常见的场景，所以这里和大家再来专门分享下。 1.什么是跨域 很多人对跨域有一种误解，以为这是前端的事，和后端没关系，其实不是这样的，说到跨域，就不得不说说浏览器的同源策略。 同源策略是由 Netscape 提出的一个著名的安全策略，它是浏览器最核心也最基本的安全功能，现在所有支持 JavaScript 的浏览器都会使用这个策略。所谓同源是指协议、域名以及端口要相同。 同源策略是基于安全方面的考虑提出来的，这个策略本身没问题，但是我们在实际开发中，由于各种原因又经常有跨域的需求，传统的跨域方案是 JSONP，JSONP 虽然能解决跨域但是有一个很大的局限性，那就是只支持 GET 请求，不支持其他类型的请求，在 RESTful 时代这几乎就没什么用。 而今天我们说的 CORS（跨域源资源共享）（CORS，Cross-origin resource sharing）是一个 W3C 标准

问题： Section 4.2 of the draft OAuth 2.0 protocol indicates that an authorization server can return both an access_token (which is used to authenticate oneself with a resource) as well as a refresh_token , which is used purely to create a new access_token : OAuth 2.0协议草案的4.2节指出授权服务器可以返回 access_token （用于向资源验证自己）以及 refresh_token ，它仅用于创建新的 access_token ： https://tools.ietf.org/html/rfc6749#section-4.2 https://tools.ietf.org/html/rfc6749#section-4.2 Why have both? 为什么两者都有？ Why not just make the access_token last as long as the refresh_token and not have a refresh_token ? 为什么不将 access_token 设为

基于SpringBoot AOP面向切面编程实现Redis分布式锁 基于SpringBoot AOP面向切面编程实现Redis分布式锁 基于SpringBoot AOP面向切面编程实现Redis分布式锁 锁定的目标是确保相互排斥其访问的资源。实际上，此资源通常是字符串。使用redis实现锁主要是将资源放入redis中并利用其原子性。当其他线程访问时，如果Redis中已经存在此资源，则不允许进行某些后续操作。 Spring Boot通过RedisTemplate使用Redis，在实际使用过程中，分布式锁可以在封装后在方法级别使用，这样使用起来就更方便了，无需到处获取和释放锁。 首先，定义一个注解： @Target({ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Inherited public [@interface](https://my.oschina.net/u/996807) RedisLock { //锁定的资源，redis的键 String value() default "default"; //锁定保持时间（以毫秒为单位） long keepMills() default 30000; //失败时执行的操作 LockFailAction action() default LockFailAction

在 《微服务权限终极解决方案，Spring Cloud Gateway + Oauth2 实现统一认证和鉴权！》 一文中我们介绍了Oauth2在微服务中的使用，但是我们没有自定义Oauth2默认的处理结果。有时候我们真的很希望Oauth2中的认证授权能返回我们指定格式的结果，比如登录认证的结果、网关鉴权不通过的结果等等。本文将详细介绍Oauth2中自定义处理结果的方案，希望对大家有所帮助！ 解决什么问题 自定义Oauth2处理结果，主要是为了统一接口返回信息的格式，从下面几个方面着手。 自定义Oauth2登录认证成功和失败的返回结果； JWT令牌过期或者签名不正确，网关认证失败的返回结果； 携带过期或者签名不正确的JWT令牌访问白名单接口，网关直接认证失败。 自定义登录认证结果 认证成功返回结果 我们先来看看默认的返回结果，访问Oauth2登录认证接口：http://localhost:9201/auth/oauth/token 我们之前使用的都是统一的通用返回结果CommonResult，Oauth2的这个结果显然不符合，需要统一下，通用返回结果格式如下； /** * 通用返回对象 * Created by macro on 2019/4/19. */ public class CommonResult <T> { private long code; private

该框架称为：**light-4j **。官方网站简介：A fast, lightweight and more productive microservices framework。很简单，翻译过来就是：一个快速、轻量级和更高效的微服务框架. 为什么叫light-4j？全称应该是：Light for Java，意味着轻量级，并以闪电般的速度来进行 Java 编程. 用这个框架有什么好处？ 1. 降低成本 为什么说它能降低成本，因为它速度非常快，占用内存也非常小. 重点来了，它比类似 Spring Boot 这种内嵌 Tomcat 式的主流微服务框架平台要快 44 倍，并且只需要用其 1/5 内存，听起来是不是很牛逼，确实是节约了不少内存空间. 这是一个基准测试报告，与Spring Boot和其他微服务平台进行了比较： 详细报告： https://github.com/networknt/microservices-framework-benchmark 很强大，性能与 Go 语言并肩，并且拥有更低的平均延迟. 这也是与其他Web框架的比较： 详细报告： https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext 2.丰富的功能 具有启动/关闭挂钩和各种中间件的插件架构 分布式OAuth2

基于实践说规范 　　网上看了一些OAuth 2.0的授权方法，尽管讲解的没有什么逻辑性错误，但是存在一个问题，那就是单纯的讲解协议规范却脱离了实际的应用，缺少干货，所以才有了这篇文章，内容基于实际业务进行讲解，力求 基于实践说规范 OAuth 2.0 　　 OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。......资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。 　　OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。 授权码（authorization - code） 隐藏式（ implicit ） 密码式（password） 客户端凭证（client credentials） 分类解读 下面针对每一种进行详细的解读 　　授权码（authorization code） 　　　　该类型的授权最为常见也是最安全的授权方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌，微信、支付宝等大的开放平台使用的基本都是这种方式。 　　案例讲解：A网站要实现微信用户的授权登录功能，首先A需要在微信公众平台注册一个应用，一般需要填写应用 图标 、 名称 、 回调链接 等信息（ 有些平台需要上传对应的非对称加密的公钥用于访问的非对称加密 ）

一、前言 在之前的使用Swagger做Api文档中，我们已经使用Swagger进行开发接口文档，以及更加方便的使用。这一转换，让更多的接口可以以通俗易懂的方式展现给开发人员。而在后续的内容中，为了对api资源的保护，我们引入了认证授权方案，利用HTTP提供了一套标准的身份验证框架，服务端可以用来针对客户端的请求发送质询(challenge)，客户端根据质询提供应答身份验证凭证，进而实现对资源的保护。 因为之前在使用Swagger的系列中还没有加身份认证授权这一块，所以我们使用的接口都是没有进行资源保护的，而再后续又对认证授权这一块进行讲解又没有将Swagger好好的利用起来，使得每一次要测试授权认证的时候，都得使用postman在Hearer请求头中加入Authorization属性，导致每测试一个接口就得输入一次token令牌来实现认证，重复操作频繁，降低工作效率。 这个时候，我们刚好发现，Swagger已经帮我们是实现了一次输入令牌，不同接口多次调用，提高效率。这样，我们就可以将之前的Swagger系列和认证授权系列相结合。 说干就干。。。 二、回顾 Swagger系列： 基于.NetCore3.1系列 —— 使用Swagger做Api文档 (上篇) 基于.NetCore3.1系列 —— 使用Swagger做Api文档 (下篇) 基于.NetCore3.1系列 ——