西安网站建设哪家好,白山市城乡建设局网站,赣州做网站找谁,梵克雅宝官网手链报价作者罗锦华#xff0c;API7.ai 技术专家/技术工程师#xff0c;开源项目 pgcat#xff0c;lua-resty-ffi#xff0c;lua-resty-inspect 的作者。 OAuth 的背景
OAuth#xff0c;O 是 Open#xff0c;Auth 是授权#xff0c;也就是开放授权的意思。OAuth 始于 2006 年API7.ai 技术专家/技术工程师开源项目 pgcatlua-resty-ffilua-resty-inspect 的作者。 OAuth 的背景
OAuthO 是 OpenAuth 是授权也就是开放授权的意思。OAuth 始于 2006 年其设计初衷正是委托授权就是让最终用户也就是资源拥有者将他们在受保护资源服务器上的部分权限例如查询当天订单委托给第三方应用使得第三方应用能够代表最终用户执行操作查询当天订单。
OAuth 1.0 协议于 2010 年 4 月作为 RFC 5849 发布这是一份信息性的评论请求。OAuth 2.0 框架的发布考虑了从更广泛的 IETF 社区收集的其他用例和可扩展性要求。尽管基于 OAuth 1.0 部署体验构建OAuth 2.0 并不向后兼容 OAuth 1.0。OAuth 2.0 于 2012 年 10 月作为 RFC 6749 发布承载令牌使用作为 RFC 6750 发布。
在 OAuth 协议中通过为每个第三方软件和每个用户的组合分别生成对受保护资源具有受限的访问权限的凭据也就是访问令牌来代替之前的用户名和密码。而生成访问令牌之前的登录操作又是在用户跟平台之间进行的第三方软件根本无从得知用户的任何信息。
这样第三方软件的逻辑处理就大大简化了它今后的动作就变成了请求访问令牌、使用访问令牌、访问受保护资源同时在第三方软件调用大量 API 的时候不再传输用户名和密码从而减少了网络安全的攻击面。
说白了就是集中授权。
值得注意的是OAuth 并非身份验证这里的 Auth 是 AuthorizationOAuth 是发生在用户做了身份验证后的事情系统授权用户能做什么操作。互联网中所有的受保护资源几乎都是以 Web API 的形式来提供访问的。不同的用户能做的事情不同例如一个 GitHub 项目有些用户只有读取和提交 PRpull request的权限而管理员用户则能合并 PR。将用户权限在 API 层面细分是 OAuth 要做的事情。
OAuth的授权流程
角色
在 OAuth 2.0 的体系里面有四种角色
第三方应用一般分为前端浏览器、APP 和后端应用服务器。资源拥有者使用第三方应用的用户并在授权服务器上有账号。授权服务提供授权的开发平台例如微博、GitHub、微信。受保护资源用户的各类信息例如用户名、头像、昵称、邮箱等信息。
流程 步骤A第三方应用向用户其实是通过授权服务器申请授权码
步骤B授权服务器返回授权码给第三方应用
步骤C第三方应用将授权码发给资源服务器申请访问口令
步骤D授权服务器返回访问口令给第三方应用
步骤E第三方应用使用访问口令向资源服务器请求用户信息
步骤F资源服务器返回用户信息第三方应用提供业务逻辑给用户
授权码和访问口令
获取访问口令的方式在标准里有四种这里只谈论授权码方式这也是最常见最安全的方式 步骤 A第三方应用让用户选择授权方式例如 GitHub然后携带client_id和redirect_uri等参数将用户重定向到授权服务器
请求示例 GET /authorize?response_typecodeclient_ids6BhdRkqt3statexyzredirect_urihttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.13 Host: server.example.com
步骤 B用户登录和授权 步骤 C授权服务器根据redirect_uri将用户重定向回到第三方应用的后端提供授权码
响应示例
1 HTTP/1.1 302 Found
2 Location: https://client.example.com/cb?codeSplxlOBeZQQYbYS6WxSbIA
3 statexyz
步骤 D第三方应用的后端访问授权服务器用授权码去换访问口令 请求示例
1 POST /token HTTP/1.1
2 Host: server.example.com
3 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
4 Content-Type: application/x-www-form-urlencoded
5
6 grant_typeauthorization_codecodeSplxlOBeZQQYbYS6WxSbIA
7 redirect_urihttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
步骤 E授权服务器返回访问口令第三方应用的后端渲染功能页面对应步骤C给浏览器为用户提供功能 授权服务器的响应示例 HTTP/1.1 200 OKContent-Type: application/json;charsetUTF-8Cache-Control: no-storePragma: no-cache{access_token:2YotnFZFEjr1zCsicMWpAA,token_type:example,expires_in:3600,refresh_token:tGzv3JOkF0XG5Qx2TlKWIA,example_parameter:example_value}
实际场景示例
小明想通过小兔软件打印他在京东上的订单。
资源拥有者 - 小明
第三方软件 - 小兔软件
授权服务 - 京东商家开放平台的授权服务
受保护资源 - 小明店铺在京东上面的订单 为什么授权码和访问口令要分开获取呢
OAuth2 协议中用户登录成功后OAuth2 认证服务器会将用户的浏览器回调到一个回调地址并携带一个授权码 code。这个授权码 code 一般有效期十分钟且一次有效用后作废。这避免了在前端暴露 access_token 或者用户信息的风险access_token 的有效期都比较长一般为 1~2 个小时。如果泄露会对用户造成一定影响。后端收到这个 code 之后需要使用 Client Id Client Secret Code 去授权服务器换取用户的 access_token。
在这一步实际上授权服务器对第三方应用进行了认证能够确保来授权服务器获取 access_token 的机器是可信任的而不是任何一个人拿到 code 之后都能来授权服务器进行 code 换 token。如果 code 被黑客获取到如果他没有 Client Id Client Secret 也无法使用就算有也要和真正的应用服务器竞争因为 code 一次有效用后作废加大了攻击难度。相反如果不经过 code 直接返回 access_token 或用户信息那么一旦泄露就会对用户造成影响。
简单说就是client secret 不能暴露给前端验证 client用户授权获取 code又只能前端做因此需要分两步。
OIDCOpenID Connect
既然 OAuth 本身就隐含了身份验证那么为什么不以标准化的形式将身份验证的结果导出使得第三方应用可以使用呢这就是 OIDC 要做的事情了。那身份验证的结果是什么很简单它就是用户的各种信息。
OIDC 怎么做简单来说就是在 OAuth 返回 access token 的时候顺带返回 id tokenid token 的格式是 JWT第三方应用可使用非对称公钥或者对称密码验证 id token 的合法性和有效性而 id token 本身也包含了基本用户信息。另外OIDC 提供了 UserInfo endpoint第三方应用可携带 access token 访问该 endpoint 以获取额外的用户信息。
OIDC 还有一个好处就是单点登录SSOSingle Sign On和单点注销SLOSingle LogOut。跟 OAuth 类似OIDC 提供的集中化身份验证它可以对应多个应用。只要用户成功登录了一个应用那么当他登录其他应用的时候就无需再进行一次身份验证了例如输入用户名密码那是因为授权服务器在用户的浏览器里面存下了 cookie。而单点注销则是用户注销了一个应用其他应用也顺便注销了注销既可以借由浏览器来做也可以由第三方应用的后端与授权服务器之间来做。注销的时候指定的参数就是 id token 里面的 session 字段。 注意OIDC 并没有指定身份验证的具体方式例如传统的密码或者刷脸而是指定了如何将身份验证委托给一个集中化的身份验证提供者在身份验证通过后得到什么凭证id token这个凭证如何被校验JWT 格式这个凭证包含了哪些用户信息。这样第三方应用就无需重造轮子了。OAuth 提供了集中化的授权而 OIDC 则是在此基础上进一步提供了集中化的身份验证。 APISIX 对 OAuth/OIDC 的支持
Apache APISIX 是一个开源的云原生 API 网关作为 API 网关它兼具动态、实时、高性能等特点提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。你可以使用 APISIX 来处理传统的南北向流量以及服务间的东西向流量也可以当做 K8s Ingress controller 来使用。
APISIX 既然是 API 网关为多个上游应用服务器做代理那么集中授权、集中身份认证放在 API 网关是最自然不过的事情了。
APISIX 的 openid-connect 插件支持 OpenID Connect 协议用户可以使用该插件让 APISIX 对接众多认证鉴权软件如 Okta、Keycloak、Ory Hydra、Authing 等作为集中式认证网关部署于企业中。OIDC是OAuth的超集所以这个插件也隐含了对OAuth的支持。
部署图如下所示 配置实例使用 Keycloak 与 API 网关保护你的 API配置 Keycloak
信息取值keycloak地址http://127.0.0.1:8080/RealmmyrealmClient TypeOpenID ConnectClient IDmyclientClient Secrete91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhqRedirect URIhttp://127.0.0.1:9080/anything/callbackDiscoveryhttp://127.0.0.1:8080/realms/myrealm/.well-known/openid-configurationLogout URI/anything/logoutUsernamemyuserPasswordmyrealmRealmmypassword
场景示例
curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 -d {uri:/anything/*,plugins: {openid-connect: {client_id: myclient,client_secret: e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq,discovery: http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration,scope: openid profile,bearer_only: false,realm: myrealm,redirect_uri: http://127.0.0.1:9080/anything/callback,logout_path: /anything/logout}},upstream:{type:roundrobin,nodes:{httpbin.org:80:1}}
}
创建 API 成功后访问 http://127.0.0.1:9080/anything/test 时由于未进行登录因此将被引导到 Keycloak 的登录页面 输入账号myuser、密码mypassword完成登录后成功跳转到 http://127.0.0.1:9080/anything/test 页面 访问 http://127.0.0.1:9080/anything/logout 退出登录 总结
本文介绍了 OAuth 协议由来和授权流程引入更上一层的身份层协议 OIDC 并提供了详细的配置示例。 作为最流行的鉴权方式OAuth/OIDC 通过 APISIX 的鉴权插件在 API 网关层面进行集中化鉴权管理使得客户端和上游服务器之间免去重复繁琐的鉴权部署和维护。
