oauth

spring oauth2+JWT后端自动刷新access_token

别来无恙 提交于 2020-08-18 12:23:11
这段时间在学习搭建基于spring boot的spring oauth2 和jwt整合。 说实话挺折腾的。使用jwt做用户鉴权,难点在于token的刷新和注销。 当然注销的难度更大,网上的一些方案也没有很出色的。这个功能基本让我放弃了jwt(滑稽笑~)。 所以今天我单纯的先记录jwt token的刷新。 Token刷新 jwt token刷新方案可以分为两种:一种是校验token前刷新,第二种是校验失败后刷新。 我们先来说说第二种方案 验证失效后,Oauth2框架会把异常信息发送到OAuth2AuthenticationEntryPoint类里处理。这时候我们可以在这里做jwt token刷新并跳转。 网上大部分方案也是这种:失效后,使用refresh_token获取新的access_token。并将新的access_token设置到response.header然后跳转,前端接收并无感更新新的access_token。 这里就不多做描述,可以参考这两篇: https://www.cnblogs.com/xuchao0506/p/13073913.html https://blog.csdn.net/m0_37834471/article/details/83213002 接着说第一种,其实两种方案的代码我都写过,最终使用了第一种。原因是兼容其他token刷新方案。

到底什么是 OAuth 2.0?

喜你入骨 提交于 2020-08-18 08:46:28
作者:阮一峰 http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版。 本文对OAuth 2.0的设计思路和运行流程,做一个简明通俗的解释,主要参考材料为RFC 6749。 一、应用场景 为了理解OAuth的适用场合,让我举一个假设的例子。 有一个"云冲印"的网站,可以将用户储存在Google的照片,冲印出来。用户为了使用该服务,必须让"云冲印"读取自己储存在Google上的照片。 问题是只有得到用户的授权,Google才会同意"云冲印"读取这些照片。那么,"云冲印"怎样获得用户的授权呢? 传统方法是,用户将自己的Google用户名和密码,告诉"云冲印",后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。 (1)"云冲印"为了后续的服务,会保存用户的密码,这样很不安全。 (2)Google不得不部署密码登录,而我们知道,单纯的密码登录并不安全。 (3)"云冲印"拥有了获取用户储存在Google所有资料的权力,用户没法限制"云冲印"获得授权的范围和有效期。 (4)用户只有修改密码,才能收回赋予"云冲印"的权力。但是这样做,会使得其他所有获得用户授权的第三方应用程序全部失效。 (5)只要有一个第三方应用程序被破解

4.13. 逻辑漏洞 / 业务漏洞

十年热恋 提交于 2020-08-18 05:28:38
文章目录 4.13. 逻辑漏洞 / 业务漏洞 4.13.1. 简介 4.13.2. 安装逻辑 4.13.3. 交易 4.13.3.1. 购买 4.13.3.2. 业务风控 4.13.4. 账户 4.13.4.1. 注册 4.13.4.2. 邮箱用户名 4.13.4.3. 手机号用户名 4.13.4.4. 登录 4.13.4.5. 找回密码 4.13.4.6. 修改密码 4.13.4.7. 申诉 4.13.5. 2FA 4.13.6. 验证码 4.13.7. Session 4.13.8. 越权 4.13.9. 随机数安全 4.13.10. 其他 4.13.11. 参考链接 4.13. 逻辑漏洞 / 业务漏洞 4.13.1. 简介 逻辑漏洞是指由于程序逻辑不严导致一些逻辑分支处理错误造成的漏洞。 在实际开发中,因为开发者水平不一没有安全意识,而且业务发展迅速内部测试没有及时到位,所以常常会出现类似的漏洞。 4.13.2. 安装逻辑 查看能否绕过判定重新安装 查看能否利用安装文件获取信息 看能否利用更新功能获取信息 4.13.3. 交易 4.13.3.1. 购买 修改支付的价格 修改支付的状态 修改购买数量为负数 修改金额为负数 重放成功的请求 并发数据库锁处理不当 4.13.3.2. 业务风控 刷优惠券 套现 4.13.4. 账户 4.13.4.1. 注册 覆盖注册 尝试重复用户名

OAuth(2)的理解

≡放荡痞女 提交于 2020-08-17 23:47:15
1.OAuth概念? OAuth是Open Authorization的简写,OAuth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAuth的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAuth是安全的。OAuth2.0是OAuth协议的延续版本,但不向后兼容OAuth 1.0即完全废止了OAuth1.0。 官方网站的首页简介: An open protocol to allow secure API authorization in a simple and standard method from web, mobile and desktop applications. 2.OAuth2与OAuth的不同之处? OAuth2能更好地支持不是基于浏览器的应用。对于不是基于浏览器的应用程序,这是对OAuth的主要挑战。 OAuth2.0不再需要客户端应用程序拥有密钥。 OAuth2.0的签名流程简单得多。没有更多的特殊解析,排序,或编码。 OAuth2.0的访问令牌是“短命”的。通常情况下,OAuth1.0的访问令牌可以存储一年或一年以上。 OAuth2.0使得负责处理的OAuth请求的服务器和处理用户的授权服务器之间的角色有一个干净的分离。 3.简单理解

ASP.NET Web API Demo OwinSelfHost 自宿主 Swagger Swashbuckle 在线文档

大城市里の小女人 提交于 2020-08-17 17:26:51
新建Web API工程 选Empty,勾选Web API,不要选择Web API,那样会把MVC勾上,这里不需要MVC Web API工程属性 XML文件用于生成在线文档 新建Windows服务作为Web API的宿主 WebApiHost工程属性 控制台应用程序方便调试 Windows服务安装Microsoft.AspNet.WebApi.OwinSelfHost 工程WebApiDemo需要引用Microsoft.Owin.dll WebApiDemo安装Swashbuckle 应用程序入口 using System; using System.Collections.Generic; using System.Diagnostics; using System.Linq; using System.ServiceProcess; using System.Text; using System.Threading.Tasks; namespace WebApiHost { static class Program { /// <summary> /// 应用程序的主入口点。 /// </summary> static void Main( string [] args) { RunDebug(); StartService(); } private static void

第6章

我们两清 提交于 2020-08-17 11:36:11
一、什么是ppp协议 点对点协议(PPP)为在点对点连接上传输多协议数据包提供了一个标准方法。PPP 最初设计是为两个对等节点之间的 IP 流量传输提供一种封装协议。在 TCP-IP 协议集中它是一种用来同步调制连接的数据链路层协议(OSI 模式中的第二层),替代了原来非标准的第二层协议,即 SLIP。除了 IP 以外 PPP 还可以携带其它协议,包括 DECnet 和 Novell 的 Internet 网包交换(IPX)。 二、配置PAP认证 PPP配置pap模式: hostname r1 username r2 password 0 cisco 配置允许接入的用户和密码 ip subnet-zero ! interface Serial0/1 ip address 1.1.1.1 255.255.255.252 encapsulation ppp 封装成PPP serial restart-delay 0 ppp authentication pap PPP的认证方式是PAP ppp pap sent-username r1 password 0 cisco 设置发起PAP验证的用户名和密码 对端的配置: hostname r2 username r1 password 0 cisco ip subnet-zero ! interface Serial0/1 ip

Azure AD B2C(一)初识

白昼怎懂夜的黑 提交于 2020-08-17 11:27:20
一,引言(上节回顾)   上一节讲到Azure AD的一些基础概念,以及如何运用 Azure AD 包含API资源,Azure AD 是微软提供的云端的身份标识和资源访问服务,帮助员工/用户/管理员访问一些外部资源和内部资源: • 外部资源,例如 Microsoft Office 365、Azure 门户以及成千上万的其他 SaaS 应用程序。 • 内部资源,例如公司网络和 Intranet 上的应用,以及由自己的组织开发的任何云应用。 今天,引入一个新概念:Azure Active Directory B2C。下面就开始进入正文了👇👇👇👇👇 二,正文   1,关于Azure AD B2C是什么?   Azure Active Directory B2C 也称为 Azure AD B2C,它是以服务的形式提供企业到客户的标识管理服务,用于以自定义的方式控制客户在使用 ios,android,.net,spa以及其他应用程序如何注册,登录和管理其个人资料。客户使用其首选的社交,企业或者本地账户标识对应用程序和API进行单一登录访问。   Azure AD B2C 是一种贴牌式身份验证解决方案。 你可以使用自己的品牌自定义整个用户体验,使其能够与 Web 和移动应用程序无缝融合。 可以自定义当用户注册、登录和修改其个人资料信息时 Azure AD B2C 显示的每一页。

.Net Core 2.2升级3.1的避坑指南

筅森魡賤 提交于 2020-08-17 03:30:38
写在前面   微软在更新.Net Core版本的时候,动作往往很大,使得每次更新版本的时候都得小心翼翼,坑实在是太多。往往是悄咪咪的移除了某项功能或者组件,或者不在支持XX方法,这就很花时间去找回需要的东西了,下面是个人在迁移.Net Core WebApi项目过程中遇到的问题汇总: 开始迁移 1. 修改*.csproj项目文件 <TargetFramework>netcoreapp2. 2 </TargetFramework> 修改为 <TargetFramework>netcoreapp3.1</TargetFramework> 2 修改Program public static void Main( string [] args) { CreateWebHostBuilder(args).Build().Run(); } public static IWebHostBuilder CreateWebHostBuilder( string [] args) => WebHost.CreateDefaultBuilder(args) .UseStartup <Startup>().ConfigureAppConfiguration((hostingContext, config) => { config.AddJsonFile($ " 你的json文件.json " ,

composer 提示无Token解决方法

北慕城南 提交于 2020-08-17 02:29:11
所遇场景 Could not fetch https://api.github.com/repos/RobinHerbots/jquery.inputmask/contents/bower.json?ref=03e65a2d28159e885e18acee9cae53ac6318372b, please create a GitHub OAuth token to go over the API rate limit Head to https://github.com/settings/tokens/new?scopes=repo&description=Composer+on+localhost.localdomain+2015-05-19+1651 to retrieve a token. It will be stored in "/home/vagrant/.composer/auth.json" for future use by Composer. Token (hidden): 解决方法 根据提示可以看到这里需要输入GitHub的token,进入https://github.com/settings/tokens 点击 「Generate new token」 新建一个 Token,选择默认新建就行,然后就会得到一个 Token,然后输入这个值就 OK 了

API接口设计,通信协议的整体架构

百般思念 提交于 2020-08-16 12:05:53
刚开始接触的时候,并没有考虑太多,就想提供URL,APP端通过该URL进行查询、创建、更新等操作即可。但再对相关规范进行了解后,才发现,API的设计并没有那么简单,远远不是URL的问题,而是一个通信协议的整体架构 1. 使用GET、POST、PUT、DELETE这几种请求模式 请求模式也可以说是动作、数据传输方式,通常我们在web中的form有GET、POST两种,而在HTTP中,存在下发这几种。 GET (选择):从服务器上获取一个具体的资源或者一个资源列表。 POST (创建): 在服务器上创建一个新的资源。 PUT(更新):以整体的方式更新服务器上的一个资源。 PATCH (更新):只更新服务器上一个资源的一个属性。 DELETE(删除):删除服务器上的一个资源。 HEAD : 获取一个资源的元数据,如数据的哈希值或最后的更新时间。 OPTIONS:获取客户端能对资源做什么操作的信息。 常见的请求参数 比如在数据过多, 需要对数据进行分页请求的时候, 我们应该统一 API 请求参数. 常见的有这些. limit=10 指定返回记录的数量 offset=10 指定返回记录的开始位置。 page=2&per_page=100 指定第几页,以及每页的记录数。 sortby=name&order=asc 指定返回结果按照哪个属性排序,以及排序顺序。 animal_type_id=1