oauth

Posted July 21, 2014 1.1m views SECURITY API CONCEPTUAL Mitchell Anicas Introduction OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and DigitalOcean. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices. This informational guide is geared towards application developers, and provides an overview of

本篇解决一个问题，token有效期 token是一个短活的东西，session可能是3天，但是token可能就2个小时，此时就会出现一种情况，session还有效但是token失效了，此时再拿着这个token去调用其他微服务就会失败了。 这就涉及到了OAuth2协议中的Refresh token，刷新令牌。刷新令牌说的是，不管你使用OAuth协议中的四种授权类型中的哪一种（密码模式、授权码模式、简化模式、客户端模式），当token失效的时候，你可以拿着一个refresh_token去重新获取一个令牌，而不需要输入用户名密码。这样用户拿到一个短生命周期的access_token，和一个长生命周期的refresh_token，当access_token失效的时候，就拿refresh_token去换取一个新的access_token。 理论上来说，access_token可以设置一个很长的有效期，但是这样是不安全的，只要拿到access_token，就可以访问你的服务了，所以如果这样做，风险很高。而refresh_token就不一样了，如下图可以看到，要想通过refresh_token换取access_token，需要携带clientId和clientSecret，认证服务器会校验他俩，这两者是保存在服务器端的，别人是拿不到的，所以即使别人拿到了refresh_token也是没用的。

前几篇说的都是基于session的SSO（客户端应用的session、认证服务器的session），客户端应用拿到认证服务器返回的token后，将其存在自己的session， 用户登录状态是存在服务器端的。 本篇要说的是，要实现一个基于浏览器cookie的SSO，客户端应用获取到令牌后，不是将其存到session，而是写入浏览器cookie，这个改变会带来一些列问题，本篇将解决这些问题。 在OAuth授权回调里处理 客户端应用 客户token后的改造，在OAuth授权回调里处理，拿到token后写入cookie： CookieTokenFilter 在客户端应用，引入zuul的依赖，写一个CookieTokenFilter，从cookie拿出token 加在请求头里。 package com.nb.security.admin; import com.netflix.zuul.ZuulFilter; import com.netflix.zuul.context.RequestContext; import com.netflix.zuul.exception.ZuulException; import org.apache.commons.lang3.StringUtils; import org.springframework.http.* ; import org

Spring cloud微服务安全实战 https://coding.imooc.com/class/chapter/379.html#Anchor Spring Cloud微服务安全实战-1-1 课程导学 Spring Cloud微服务安全实战- 2-1 环境安装 Spring cloud微服务安全实战-3-1 API安全 常见的安全机制 Spring cloud微服务安全实战-3-2 第一个API及注入攻击防护 Spring cloud微服务安全实战-3-3 API安全机制之流控 Spring cloud微服务安全实战-3-4 API安全机制之认证（1） Spring cloud微服务安全实战-3-5 API安全机制之认证（2） Spring cloud微服务安全实战-3-6API安全机制之数据校验 Spring cloud微服务安全实战-3-7API安全机制之数据加密 Spring cloud微服务安全实战-3-8API安全机制之Https Spring cloud微服务安全实战-3-9API安全机制之审计日志 Spring cloud微服务安全实战-3-10API安全机制之授权 Spring cloud微服务安全实战-3-11API安全机制之登录 Spring cloud微服务安全实战-3-12session固定攻击防护 Spring cloud微服务安全实战-3

Code在Oauth2.0和OpenId Connect里面分别叫做不同的名字 OAuth只介绍了如何授权。没有介绍如何身份认证、 OpenId Connect：既规定了怎么授权，也规定了怎么身份认证 OpenlD Connect是在OAuth2.0身份证协议之上做的身份认证协议，它里面规定了三种flow分别是 Authorization Code Flow、Implicit Flow、 Hybird Flow 今天主要讲Authoriztion Code， OAuth2.0里面的流程图 OpenId Connect 不一定的地方主要是这里，除了会获取access token之外，还会获取 Id token 新建MVC的客户端应用 修改启动的端口为5002 startUp里面。把JWT的Claim类型映射关闭了以便允许有一个WhereNo的Claim。如果不关闭的话它就会修改从授权服务器返回的各种Claim 然后注册身份认证中间件；cookie的名称要保持一致 AddCookie表示使用Cookie来验证的首选方式 授权服务器的地址： 设置不需要Https 表示把获取的token存到cookie里面，因为以后可能会用 先把Scope清空，再去添加Scope 添加身份认证的中间件 然后保护HomeController，只有授权用户才可以访问这个Controller 服务端的设置

授权模式改造成了Authorization code完成了改造的同时也实现了SSO。微服务环境下的前后端分离的单点登陆。 把admin的服务重启。刷新页面 并没有让我去登陆，直接就进入了首页。 order的API控制台 只要你在认证服务器上的session没过期。认证服务器就知道你是谁，他就不会让你输入用户名密码了。直接跳回到客户端应用。 一共有三个有效期。 退出操作 退出的时候。现在前端服务器清空session，认证服务器也需要清空session 在前端服务器退出后，再跳转到认证服务器执行退出。logout是spring security默认的退出路径 这时候跳转到了认证服务器。 点击退出后 如果再次输入账号密码登录 这时候没跳转会前端， 这是个404的页面。 这是因为我们之前触发的登陆页面的请求，是下面这样的一个请求 这里他是不知道是要跳转回admin的应用的，所以默认进去了自己的主页。 :9090/根目录，这个主页没做任何的处理 所以是一个404页面。 退出操作优化 退出的时候加一个参数redirect_uri 认证服务器改造 首先要找到处理logout这个请求的代码。 它会拦截logout的方法，然后 拦住以后会生成一个页面出来。 页面上很简单，上面一个提示语，问题你是不是确认要退出。点了按钮就会提交这个表单。 我们来复制这个类，首先在我们的代码里面建一个一模一样的包

文章来源：https://www.cnblogs.com/jsjwk/p/11015666.html 应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题。尤其是在我们采用了微服务架构之后，项目的复杂度提升了N个级别，相应的，微服务的安全工作也就更难更复杂了。并且我们以往擅长的单体应用的安全方案对于微服务来说已经不再适用了。我们必须有一套新的方案来保障微服务架构的安全。 在探索微服务访问安全之前，我们还是先来回顾一下单体应用的安全是如何实现的。 一、传统单体应用如何实现「访问安全」？ 下图就是一个传统单体应用的访问示意图： （图片来自WillTran在slideshare分享） 在应用服务器里面，我们有一个auth模块（一般采用过滤来实现），当有客户端请求进来时，所有的请求都必须首先经过这个auth来做身份验证，验证通过后，才将请求发到后面的业务逻辑。 通常客户端在第一次请求的时候会带上身份校验信息（用户名和密码），auth模块在验证信息无误后，就会返回Cookie存到客户端，之后每次客户端只需要在请求中携带Cookie来访问，而auth模块也只需要校验Cookie的合法性后决定是否放行。 可见，在传统单体应用中的安全架构还是蛮简单的，对外也只有一个入口，通过auth校验后，内部的用户信息都是内存/线程传递，逻辑并不是复杂，所以风险也在可控范围内。 那么

从1月份首次公开介绍这个项目到现在也快4个月了，期间做了一些修修补补整体没什么大的改动。2.0算是发布之后第一个大的版本更新，带来了许多新功能新特性，也修复了一些已知的bug，在此感谢在博客、Issue和QQ群中提出各种意见的朋友，以及指导过我的前辈大佬们。 在我看来，这个项目没有使用任何高深的技术和架构，甚至有些代码写的自己都不满意不敢拿出来给大家观赏，和社区中其他一些开源项目的大佬们比起来自惭形秽。但是这几个月陆续收到一些小伙伴的支持和鼓励，也被一些源码网站收录和推荐，让我有勇气和信心把它继续做下去，贵在坚持吧。 新版本主要是增加了HTTP任务调度以及节点管理功能，开发过程中重构了部分代码，本来还打算完善一下单元测试，由于时间关系无奈延后了。 不太熟悉的朋友可以看下之前的介绍： https://www.cnblogs.com/hohoa/p/12162581.html https://www.cnblogs.com/hohoa/p/12197518.html 新版本特性 完善了任务生命周期事件 任务列表支持节点名称搜索和显示优化 支持配置HTTP任务 支持节点手动管理 支持在程序集任务中指定自定义配置文件 支持长任务取消 新增了一些系统策略配置 新增了动态参数启动，对容器部署更友好 推出正式文档 补充了一些使用demo 修复若干bug

从1月份首次公开介绍这个项目到现在也快4个月了，期间做了一些修修补补整体没什么大的改动。2.0算是发布之后第一个大的版本更新，带来了许多新功能新特性，也修复了一些已知的bug，在此感谢在博客、Issue和QQ群中提出各种意见的朋友，以及指导过我的前辈大佬们。 在我看来，这个项目没有使用任何高深的技术和架构，甚至有些代码写的自己都不满意不敢拿出来给大家观赏，和社区中其他一些开源项目的大佬们比起来自惭形秽。但是这几个月陆续收到一些小伙伴的支持和鼓励，也被一些源码网站收录和推荐，让我有勇气和信心把它继续做下去，贵在坚持吧。 新版本主要是增加了HTTP任务调度以及节点管理功能，开发过程中重构了部分代码，本来还打算完善一下单元测试，由于时间关系无奈延后了。 不太熟悉的朋友可以看下之前的介绍： https://www.cnblogs.com/hohoa/p/12162581.html https://www.cnblogs.com/hohoa/p/12197518.html 新版本特性 完善了任务生命周期事件 任务列表支持节点名称搜索和显示优化 支持配置HTTP任务 支持节点手动管理 支持在程序集任务中指定自定义配置文件 支持长任务取消 新增了一些系统策略配置 新增了动态参数启动，对容器部署更友好 推出正式文档 补充了一些使用demo 修复若干bug

1. Http basic Authorization 基于浏览器的一种鉴权方式。 1. 未授权请求，拦截，返回 401 Unauthorised 2. 支持的浏览器弹出用户名密码框，输入用户名密码，连同上次请求数据，一起发送到服务端 使用授权头，Authorization: Basic [base64]编码的用户名密码 3. 服务端验证通过，返回资源 4. 客户端会一种携带授权头，不安全，适用于内网 2. session-cookie 用户未登录，无sessionId，客户端登录后，在cookie中种下sessionId，发送到服务端，服务端验证通过，释放资源。 sessionId过期，重新登录，http请求，后端会redirect到登录页，ajax请求或前端route，需要前端全局拦截 3. Token 用户未登录，无token，登录后，返回token，客户端可以存储在cookie，storage，或内存中，每次请求携带token， 其灵活的特点是，不必须依赖cookie，可以在任何终端使用，多用于app鉴权。 Token过期，重新登录，请求拦截通session-cookie 4. OAuth OAuth2.0流程: 1. 第三方应用在资源方注册，获取身份，无身份后面请求无效 2. 第三方应用征得用户授权，同意获取资源 3. 第三方应用向资源方请求授权码，资源方返回授权码 4.