那个网站做h5不要钱网站设计论文的题目

那个网站做h5不要钱,网站设计论文的题目,xampp php网站模板,怎么搭建国外网络简介最近在工作中遇到了一个问题#xff0c;在实现OAuth2的过程中#xff0c;发现公司的实际落地与理论不完全相同。故此复习一下。What is OAuth2?OAuth2(OAuth2.0)是一个开放标准的授权框架#xff0c;用于第三方应用(客户端)在取得用户(资源所有者)的授权下#xff0c;…简介最近在工作中遇到了一个问题在实现OAuth2的过程中发现公司的实际落地与理论不完全相同。故此复习一下。What is OAuth2?OAuth2(OAuth2.0)是一个开放标准的授权框架用于第三方应用(客户端)在取得用户(资源所有者)的授权下可以访问用户敏感信息。而无需向第三方应用暴露账号密码。核心是授权而非认证设计之初聚焦于权限管理OAuth2诞生的初衷是为了避免第三方应用获取用户的原始密码同时让用户(资源所有者)自主控制第三方应用(客户端)对自己敏感信息的访问权限(比如只读修改删除)其本质是授权第三方有限度的使用资源。本身不参与认证在OAuth2流程中用户身份的验证始终由资源所有者的平台负责(比如微信GITHUB)由它们提供Login页面。OAuth本身不参与用户身份的验证它只是在验证通过后传递已授权的凭证。仅仅是一份授权证明OAuth2最终发放的是访问令牌(Access Token)它仅仅代表用户允许第三方应用如何访问特定资源不包含用户身份信息也不能作为用户身份的证明。举个例子使用该Access Token在https://www.jwt.io/ 中解析。eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzQ1Niwic2NvcGUiOiJwcm9maWxlIG9wZW5pZCIsImV4cCI6MTczMzcwMjQwMCwiaWF0IjoxNzMzNjk4ODAwLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20ifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cimage核心角色OAuth2定义了4个核心角色所有流程都围绕这4个角色展开角色 含义 举个例子资源所有者 用户本身有权决定是否授权客户端访问自己的资源 使用微信的你客户端 第三方应用希望访问用户(也就是你)的敏感信息 比如小红书希望访问你微信上的照片头像昵称等image授权服务器 由资源服务器提供验证用户的身份生成授权凭证(Access Token) 微信的授权服务器 image资源服务器 存储受保护资源的服务器接收并验证客户端的Access Token 微信的用户信息服务器存储你的头像、昵称等只有验证令牌后才返回。image核心授权类型(Grant Type)OAuth2根据客户端的类型(是否有服务器是否能安全存储密钥)定了多种Grant Type。授权码模式(Authorization Code)适用场景 有自己服务器的客户端能够安全存储客户端密钥不会暴露给前端特点 通过授权码间接获取访问令牌是最常用也是最安全的模式。隐式模式Implicit适用场景 有自己服务器的客户端(比如无需与后端交互的纯前端应用)无法安全存储客户端密钥密钥会暴露在前端代码中特点跳过“授权码”步骤直接从授权服务器获取访问令牌通过URL片段返回不返回刷新令牌。缺点访问令牌直接暴露在前端安全性较低可能被拦截。密码模式Resource Owner Password Credentials适用场景客户端与资源所有者高度信任如公司内部应用用户愿意向客户端提供账号密码。流程用户直接向客户端输入账号密码客户端拿着密码向授权服务器请求访问令牌如“公司内部APP用域账号密码登录获取员工信息系统的访问权限”。缺点客户端获取了用户密码违背OAuth“不暴露密码”的初衷。客户端模式Client Credentials适用场景客户端访问自己的资源非用户个人资源无需用户授权。流程客户端直接用自己的客户端ID和密钥向授权服务器请求访问令牌如“天气APP的后端服务用自己的凭证获取天气数据API的访问权限”。重点关注授权码模式Authorization Code即可剩下的三种纯属凑数。谁敢在生产环境暴露密钥谁又能保证密钥永远不会泄露核心凭证OAuth2中有3种关键凭证用于确保授权流程的安全性授权码(Authorization Code)短期有效(几分钟)由授权服务器在用户同意授权后生成。仅能使用一次兑换令牌后失效避免被劫持后重复使用。访问令牌Access Token客户端访问资源服务器的key包含了授权范围(比如只能访问头像不能访问手机号)通常为JWT资源服务器通过它验证客户端的访问权限。刷新令牌(Refresh Token)长期有效(几天到几个月)用户在Access Token过期后无需重新授权直接获取Access Token。Authorization Code 核心流程imageQ1:授权服务器生成Code之后redirect_uri重定向回前端还是后端授权服务器生成 Code 后通过 redirect_uri 首先发送给第三方客户端的前端浏览器 / APP再由前端中转到客户端的后端最终由后端用 Code 交换 Access Token。Q2为什么Code一定要重定向回前端后端不行吗可以但会造成如下几个问题用户授权流程的缺失当用户同意授权后如果直接发给后端。那么用户的前端页面完全不知道授权结果比如用户在微信登录页授权后浏览器还停留在微信页面不知道该跳转回到客户端哪里。授权流程被割裂对于用户体验不好。无法验证客户端的合法性如果直接发后端授权服务器只能通过RedirectUri来判断但这个地址可能会被伪造比如攻击者伪装成客户端后端地址诱导授权服务器把 Code 发给他。HTTPS的中间人攻击也是这个原理。而通过前端重定向「用户的上下文」就是天然的验证用户是从客户端前端跳转去授权服务器的授权后跳回客户端前端相当于用户 “背书” 了这个客户端的合法性避免了攻击者伪造后端接收 Code 的风险。网络可达性问题后端地址可能是企业内网也可能是有防火墙跳板机堡垒机等保护。授权服务器根本无法直接访问这些后端接口。而网页前端天生自带公网IP授权服务器只需通过 “跳转” 把 Code 交给前端再由前端中转给后端完美解决了 “授权服务器找不到客户端后端” 的问题为什么OAuth2与SSO经常混为一谈SSO是一种业务目标而OAuth2是实现该目标的常用方案之一。它们是两个不同的概念既不冲突也不等同而是 “目标与工具” 的关系。OAuth2可以实现SSO但不是SSO的唯一实现方式。还有其它协议比如SAML2.0CAS以及非常轻量化的Cookie共享Ticket自包含等方案。它们混淆的根源在于场景高度重叠OAuth2最常见的场景就是第三方登录比如使用微信登录美团淘宝等第三方客户端。在用户的视角下只要使用微信登录就能登录多个应用一气呵成很流畅很润对于用户最直观的感受就是这就是SSO。image在开发者的视角下对接第三方登录时市面上90%的方案就是OAuth2协议久而久之就形成了刻板印象与路径依赖。概念边界很模糊认证与授权往往同时出现主流基于OAuth2的SSO方案不会只做身份认证还会同步处理权限校验。而OAuth2刚好能同时解决导致SSO与OAuth2深度绑定难以拆分理解我就经常混淆.NET中app.UseAuthentication()与app.UseAuthorization() ,他们两个的单词拼写都很接近更别说概念了。两者核心差异OAuth2的核心是授权即使不用来做SSO它也能单独解决第三方应用访问用户资源的问题。SSO的核心是认证即使不用OAuth2,它也能解决重复登录的问题比如使用JWT形式的Ticket也能实现SSO与授权无关。OAuth2如何勾搭上SSO的在文章中一直强调OAuth2是对资源的管理好像跟认证没啥关系啊。为什么能扯上关系正所谓弹道也是道枪法也是法保时捷也是劫。当今互联网识别用户唯一标识的主流分别是EmailPhone。我们可以把这两者当作一种资源去申请申请到之后跟自己数据库匹配如果存在那就直接颁发ticket/cookie如果不匹配就自动创建用户并颁发ticket/cookie。 从而以一种曲线救国的方式完成了免密登录。image简单DEMOhttps://gitee.com/lmy5215006/auth-learning-workimageimageimage埋了一个彩蛋再次解释了为什么Code一定要重定向回前端。