什么是IDaaS?一文带你全面了解IDaaS!
发布网友
发布时间：2024-09-06 07:39
共1个回答
热心网友
时间：2024-09-12 02:20
IDaaS身份是什么？它又存在什么样的价值？让我们一探究竟。
在构建数字身份平台的过程中，产生了IAM（IdentityandAccessManagement），即“身份识别与访问管理”。传统IAM服务虽然解决了部分身份问题，但开发效率低，成本浪费严重。我们每开发一个应用，就要进行一次用户系统的开发，并且实施复杂。
IDaaS是在IAM基础上加上了云计算，基于云原生架构、天然适应，实现海量数据存储，多维度保障数据安全。
本文将从以下三方面论述IDaaS的价值：
IDaaS的发展历程
IDaaS的五统能力
IDaaS背后的认证和授权基石
一、SaaS+IAM=IDaaS1.SaaS软件即服务软件即服务：SoftwareasaService，缩写就是我们常说的SaaS。
即服务（aaS）通常是指由别人（一般指云服务厂商）提供的服务，它可以让个人或企业专注于自身更重要的业务。
在SaaS这种软件交付模式下，软件不再需要复杂的安装部署过程，只需通过网络连接就可直接使用，软件及其数据托管在云服务厂商中，厂商将全程负责处理软件更新、漏洞修复等维护工作。用户通常通过Web浏览器或API连接就可以使用软件。
例如腾讯云直播的SaaS方案，以及MicrosoftOffice365其实也是一种典型的针对个人用户的SaaS应用。
和SaaS对应的还有另外两种交付模式：IaaS和PaaS。
交付模式对比图[1]上图的湖蓝色模块代表企业需要自行实现的服务，而红色模块代表云服务厂商所提供的即用服务。
On-site，所有的一切都在用户本地部署。
IaaS，全称InfrastructureasaService，基础设施即服务。主要提供一些基础资源，包括实际的服务器、网络、虚拟化和存储。例如，我们买了个腾讯或阿里云服务器，在上面自行搭建所需环境并部署我们的软件。
PaaS，全称PlatformasaService，平台即服务。主要面向开发人员，云服务厂商在提供基础设施之余，还提供业务软件的运行环境，以集成解决方案或服务的形式将该平台交付给用户。例如，腾讯云的微服务平台TSF提供了基于SpringCloud和ServiceMesh两种微服务架构的支持。
PaaS其实也是SaaS模式的一种应用，但区别在于，SaaS面向的不是软件的开发人员，而是软件的最终用户。
有个生动形象的PizzaasaService[2]的例子可以阐述SaaS，PaaS，IaaS三者的区别。
对应上面，大抵意思就是：
On-site，在家自己做披萨；IaaS，买速食披萨回家自己做着吃；PaaS，叫外卖将披萨送到家里吃；SaaS，在披萨店吃披萨。2.IAM身份和访问管理服务IAM全称IdentityandAccessManagement，
是一种Web服务，可以帮助用户安全地控制对资源的访问。通俗来说，就是可以使用IAM来控制谁通过了身份验证（准许登录）并获得授权（拥有权限）来使用资源。详细可以查看AWSIAM文档[3]。
与聘请一个保安在大厦门口相似，企业的应用程序接入IAM服务后，就可以“高枕无忧”，IAM会帮你控制谁有访问应用的权限。
3.IDaaS身份即服务来到本文的主角，身份即服务：IdentityasaService。
Identity就是IAM中的身份概念，asaService就是开篇介绍的SaaS。
IDaaS实际上就是一个基于SaaS模式的IAM解决方案，也就是云上的身份和访问管理服务，完全由受信任的第三方云服务厂商托管和管理。它允许企业使用单点登录、身份验证和访问控制来提供对任意接入的已实现标准协议应用的安全访问。
根据IDaaS厂商提供的功能，某种程度下，你甚至可以认为IDaaS就是IAM。
国内目前了解到的IDaaS厂商有，腾讯云IDaaS[4]，阿里云应用身份服务IDaaS[5]，Authing[6]。在云计算、云原生领域，很多时候想要了解一个产品，其实可以去上述三家企业官网看看，多参考参考他们的现成方案。点击查看Authing开发者文档
二、IDaaS的五统能力IDaaS的功能可以合称为5A能力[7]：Account、Authentication、Authorization、Application、Audit。
但我愿称其为五统能力：
1.统一账号管理Account模块的管理，这块容易理解。你想最基本的一块，应用程序要想实现单点登陆的话，
单点登录（SingleSignOn），简称为SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
A系统使用了user1登录成功后，B系统随之也以user1的身份登录成功了。例如淘宝taobao.com和天猫tmall.com两个站点。
那其账号是不是必须得统一放在一处（IDaaS）进行会话管理。
不过通常由于业务需要，应用系统和IDaaS还得做一次账号同步（SCIM/LDAP方式）。
2.统一身份认证身份认证叫做Authentication。更形象化就是指你在应用上通过输入账号密码、验证码或扫码等方式进行登录的这个过程。
而这个过程IDaaS所使用的认证协议会帮你做了，而且把登录页面都给做了，直接喂到你嘴里，你应用只需要重定向过来即可。
身份认证协议有很多种：OIDC/SAML等。下文我会再着重讲述OIDC协议。
3.统一授权管理Authorization是授权，切忌别和认证Authentication混淆。
授权是指客户端经过身份认证成功后，能够以有限的权限去访问服务端资源的一种机制。
IDaaS的授权架构一般会选用基于角色的权限访问控制（RBAC）。
常用的授权模式的话有基于OAuth2.0框架的授权码模式，这部分我也会在下文的OIDC章节重点讲诉。
4.统一应用管理Application应用包括企业接入进来的自身应用以及IDaaS所提供的一些可选模板应用（如GitLab、Grafana等）。
IDaaS自身提供统一标准规范，对应用统一管理，例如可以控制应用是否支持单点登录，控制应用的可访问成员等。
5.统一审计管理Audit审计，没什么好讲的，业务角度，代码埋点，Webhook等方式记录下应用和用户相关的操作日志，便于管理员分析系统的日常操作与安全事件数据。
三、OIDC身份认证协议接下来将进入本文核心内容，讲述IDaaS背后支撑着认证和授权能力的基石：OAuth2.0和OIDC协议。
1.OAuth2.0OAuth即OpenAuthorization，开放授权。
OAuth2.0（RFC6749[8]）是一个授权标准协议，可以使第三方应用获得对资源服务的有限访问。
根据OAuth2.0协议规范，定义了四个角色：
资源所有者（ResourceOwner）：能够授予对受保护资源访问权限的实体。例如应用的用户是资源的所有者，可以授权其他人访问他的资源。当资源所有者是一个人时，它被称为最终用户。
资源服务器（ResourceServer）：存储受保护资源的服务器，能够接受并使用访问令牌来响应受保护的资源请求。就是资源服务器接受AccessToken，然后验证它拥有的权限，最后返回对应的资源。这个资源服务器一般是应用本身。
授权服务器（AuthorisationServer）：服务器向客户端（即应用）颁发访问令牌来验证资源所有者并获得授权。即负责颁发AccessToken的服务器，例如IDaaS就是一个授权服务器。
客户端（Client）：需要获取访问令牌以访问资源服务器的应用。经过授权后，授权服务器为客户端颁发AccessToken。后续客户端可以携带这个AccessToken到资源服务器那访问用户的资源。
在OAuth2.0中一个应用可能既是ResourceServer，也是Client，具体是什么角色，取决于应用工作的场景。
概念可能有点难嚼，还请慢咽。
这四个角色一直在围绕着一个叫AccessToken的东西在转圈圈。
AccessToken也就是访问令牌，它用于允许应用访问一个资源API。用户认证授权成功后，授权服务器会签发AccessToken给应用。应用后续需要携带AccessToken访问资源API，资源服务API会检验AccessToken是否有权限访问，从而决定是否返回对应资源。
而AccessToken本质上只是一串随机字符串，并不能从中获取到任何信息，检验AccessToken的步骤还需要资源服务器将它转发到授权服务器上进行解析验证。
了解完AccessToken之后，我们来关注一下客户端调用方是如何获取到它的，也就是授权模式的选择。
授权码模式（AuthorizationCode）：适用于具有完整前后端的传统Web应用以及移动或桌面端应用。
隐式模式（Implicit）：适用于没有后端的基于浏览器（JavaScript）的纯前端应用。
密码模式（ResourceOwnerPasswordCredentials）：适用于资源服务器和客户端之间高度信任的情况下，例如自家应用使用自家的资源。
客户端凭证模式（ClientCredentials）：适用于没有前端参与，纯后端交互的情况，期间没有用户的参与，客户端自己就是资源所有者。......
我们重点关注授权码模式和客户端凭证模式，这两个是最常用的。
先看授权码模式，也叫code换token模式，我们以StackOverflow使用GitHub登录为例（在这个过程中StackOverflow是客户端，GitHub是资源服务器，提供邮箱头像等资源信息，同时GitHub也是授权服务器，会颁发token给客户端）。
第一步，点击登录后需要跳转到授权服务器地址，即GitHub的地址，并且必须在URL上携带client_id和redirect_uri以及scope等信息。
Apachehttps://github.com/login/oauth/authorize?client_id=01b478c0264a1fbd7183&redirect_uri=https://stackauth.com/auth/oauth2/github&response_type=code&scope=user:email&state=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxclient_id可以让GitHub知道是哪个客户端在请求资源，这里的01b478c0264a1fbd7183就是StackOverflow在GitHub中注册的客户端ID；
redirect_uri是授权成功或失败后的回调地址；
response_type=code表示使用授权码模式授权；
scope表示应用正在请求哪些权限；
state是一个随机字符串用来防止CSRF攻击。
继续第二步，当我们点击授权按钮后，这时授权服务器即GitHub会将浏览器重定向到第一步的redirect_uri参数指定的网址。并且跳转时，会携带一个授权码code参数（由GitHub后台生成的）以及state参数。
Apachehttps://stackauth.com/auth/oauth2/github?code=1efc47a278d10a04f88e&state=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx第三步，由于浏览器触发请求了redirect_uri，所以StackOverflow网站后台可以接收到请求并拿到授权码code和state，这时就可以将state和第一步生成的state对比以防止CSRF和其他相关攻击。
第四步，StackOverflow可以拿着client_id、client_secret、code跟GitHub交换令牌，GitHub收到请求以后就会校验code并颁发访问令牌（code是有过期时间的，并且是一次性的）。
Ruby//RequestPOSTcode=1efc47a278d10a04f88e&client_id=01b478c0264a1fbd7183&client_secret=xxxxxx//ResponseAccept:application/json{"access_token":"gho_16C7e42F292c6912E7710c838347Ae178B4a","scope":"user:email","token_type":"bearer"}最后第五步，StackOverflow使用GitHub颁发的访问令牌跟GitHub获取到所需的资源（用户邮箱地址），然后就走自己的业务流程了，一般就是重定向回首页。
完整的流程可以看GitHub的CreatinganOAuthAppDocs[9]。
另一个客户端凭证模式就相对简单了，毕竟只是纯后端交互。
例如，一个B应用拥有很多photo资源，即B为资源服务器（假设同时也是授权服务器），A客户端想要获取B的photo资源。
第一步，A应用直接使用client_id和client_secret向B申请资源。
Groovyhttps://b.com/oauth/token?grant_type=client_credentials&scope=photo&client_id=xxx&client_secret=xxxresponse_type=client_credentials表示使用客户端凭证模式授权。
第二步，B作为授权服务器验证A客户端的client_id和client_secret是否合法，然后颁发访问令牌。
第三步，A客户端携带访问令牌向B资源服务器获取photo资源。
这期间并没有用户的参与，A客户端自己就相当于一个“用户”。
2.OpenIDConnect讲完OAuth2.0授权，来到OIDC认证协议。
如标题，OIDC全称是OpenIDConnect[10]，
是一个基于OAuth2.0的认证+授权（OAuth2.0提供的能力）协议。
OIDC可以理解为OAuth2.0的超集，在OAuth2.0之上实现了更多的标准，例如定义了一系列的EndPoint。还有一些规范诸如SessionManagement[11]，Front-ChannelLogout[12]，Back-ChannelLogout[13]等。
OIDC之所以有认证的功能，是因为在OAuth2.0颁发AccessToken的基础上，多颁发了一个IDToken（用户的身份凭证），和AccessToken是一个随机字符串不同的是，IDToken是一个JWTToken。
IDToken自身包含了一些用户的基本信息，而且由于JWT的防篡改性，让客户端不需要再向授权服务器进行身份验证，就能直接用IDToken来进行身份验证。即使IDToken包含的用户信息不够，也可以调用OIDC定义的UserInfoEndPoint（用户信息接口）来获取更多的用户信息。
OIDC协议定义的名词和OAuth2.0协议定义的稍微有些出入：
OpenIDProvider，简称OP：相当于OAuth2.0中的授权服务器，除了负责颁发AccessToken，还会颁发IDToken。例如IDaaS就是一个OP。
RelyingParty，简称RP：代指OAuth2.0中的客户端。
EndUser，简称EU：即用户。
最后，OIDC的授权流程与OAuth2.0是一样的，主要区别在于OIDC授权流程中会额外返回IDToken。
四、云原生下的OIDCProvider服务IDaaS的认证和授权使用了OIDC/OAuth2.0。说白了，要搭建IDaaS得先搭建一个授权服务器OpenIDProvider（更多时候称之为OIDCProvider）。
但即便完全了解OIDC协议，自行实现一套完整的OIDCProvider依旧十分繁琐，好在云原生环境下孕育出了很多优秀的项目。本文会简单介绍一下Go语言生态下的dexidp/dex和ory/hydra，感兴趣的可以自行到其官网详细了解。
1.dexidp/dexDex[14]作为CNCF的一个sandbox项目，是一个具有可插拔连接器的OIDC和OAuth2.0提供商。
它通过”连接器“的身份来充当其他身份提供商的门户，可以将身份验证推送到LDAP服务器、SAML提供商或GitHub、Google和ActiveDirectory等其他一些成熟的身份提供商中进行验证。客户端只需写一次认证逻辑就可以与Dex对接，然后Dex来处理特定后端的协议。
2.ory/hydraORYHydra[15]是一个OAuth2.0和OpenIDConnect提供者。
特别一说的是Hydra所实现的OAuth2.0协议并不依赖Go标准库提供的，而是自实现的fosite[16]。
另外ORYHydra还提供了一个5分钟的快速搭建教程。
总结身份行业正全面朝着现代化身份标准发展，零信任的网络安全模型、基于区块链技术的去中心化身份认证、基于物联网（IoT）的身份认证、隐私及法规问题的解决方案等都是目前身份行业所面临的挑战和趋势。
IDaaS作为现代身份之称，正是为了支持当前和未来的变化才诞生的。借助IDaaS，可以轻松地连接到您的组织，为您提供创新未来。
而Authing正是这样一个优秀的IDaaS提供商。作为国内首款以开发者为中心的全场景身份云产品，集成了所有主流身份认证协议，为企业和开发者提供完善安全的用户认证和访问管理服务。
主要功能包括：单点登录、用户分析、扫码登录、多因素认证、行为审计、风险控制、跨平台设备管理、IoT身份认证等；兼容国际各类标准协议：OAuth2.0、OIDC、SAML、AD/LDAP、WS-Fed、JWT等；此外还有基于函数计算可以无限制拓展Authing能力的Pipeline。支持云交付和私有化部署方式，帮助企业和开发者千倍级提升生产效率。
不管是ToB、ToE的企业场景，还是ToC的终端用户场景，Authing都可以：大幅降低运营成本，提升内部管理效率；提升用户体验，提升用户运营能力。
参考资料
[1]交付模式对比图:https://www.redhat.com/zh/topics/cloud-computing/what-is-saas
[2]PizzaasaService:https://m.oursky.com/saas-paas-and-iaas-explained-in-one-graphic-d56c3e6f4606
[3]AWSIAM文档:https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/introduction.html
[4]腾讯云IDaaS:https://cloud.tencent.com/product/tcid
[5]阿里云应用身份服务IDaaS:https://www.aliyun.com/product/idaas
[6]Authing:https://www.authing.cn/
[7]5A能力:https://help.aliyun.com/document_detail/167902.html
[8]RFC6749:https://datatracker.ietf.org/doc/html/rfc6749
[9]CreatinganOAuthAppDocs:https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app
[10]OpenIDConnect:https://openid.net/specs/openid-connect-core-1_0.html
[11]SessionManagement:https://openid.net/specs/openid-connect-session-1_0.html
[12]Front-ChannelLogout:https://openid.net/specs/openid-connect-frontchannel-1_0.html
[13]Back-ChannelLogout:https://openid.net/specs/openid-connect-backchannel-1_0.html
[14]Dex:https://dexidp.io/
[15]ORYHydra:https://www.ory.sh/hydra/docs/next/
[16]fosite:https://github.com/ory/fosite
热心网友
时间：2024-12-13 15:36
IDaaS身份是什么？它又存在什么样的价值？让我们一探究竟。
在构建数字身份平台的过程中，产生了IAM（IdentityandAccessManagement），即“身份识别与访问管理”。传统IAM服务虽然解决了部分身份问题，但开发效率低，成本浪费严重。我们每开发一个应用，就要进行一次用户系统的开发，并且实施复杂。
IDaaS是在IAM基础上加上了云计算，基于云原生架构、天然适应，实现海量数据存储，*度保障数据安全。
本文将从以下三方面论述IDaaS的价值：
IDaaS的发展历程
IDaaS的五统能力
IDaaS背后的认证和授权基石
一、SaaS+IAM=IDaaS1.SaaS软件即服务软件即服务：SoftwareasaService，缩写就是我们常说的SaaS。
即服务（aaS）通常是指由别人（一般指云服务厂商）提供的服务，它可以让个人或企业专注于自身更重要的业务。
在SaaS这种软件交付模式下，软件不再需要复杂的安装部署过程，只需通过网络连接就可直接使用，软件及其数据托管在云服务厂商中，厂商将全程负责处理软件更新、漏洞修复等维护工作。用户通常通过Web浏览器或API连接就可以使用软件。
例如腾讯云直播的SaaS方案，以及MicrosoftOffice365其实也是一种典型的针对个人用户的SaaS应用。
和SaaS对应的还有另外两种交付模式：IaaS和PaaS。
上图的湖蓝色模块代表企业需要自行实现的服务，而红色模块代表云服务厂商所提供的即用服务。
On-site，所有的一切都在用户本地部署。
IaaS，全称InfrastructureasaService，基础设施即服务。主要提供一些基础资源，包括实际的服务器、网络、虚拟化和存储。例如，我们买了个腾讯或阿里云服务器，在上面自行搭建所需环境并部署我们的软件。
PaaS，全称PlatformasaService，平台即服务。主要面向开发人员，云服务厂商在提供基础设施之余，还提供业务软件的运行环境，以集成解决方案或服务的形式将该平台交付给用户。例如，腾讯云的微服务平台TSF提供了基于SpringCloud和ServiceMesh两种微服务架构的支持。
PaaS其实也是SaaS模式的一种应用，但区别在于，SaaS面向的不是软件的开发人员，而是软件的最终用户。
有个生动形象的PizzaasaService[2]的例子可以阐述SaaS，PaaS，IaaS三者的区别。
对应上面，大抵意思就是：
On-site，在家自己做披萨；IaaS，买速食披萨回家自己做着吃；PaaS，叫外卖将披萨送到家里吃；SaaS，在披萨店吃披萨。2.IAM身份和访问管理服务IAM全称IdentityandAccessManagement，
是一种Web服务，可以帮助用户安全地控制对资源的访问。通俗来说，就是可以使用IAM来控制谁通过了身份验证（准许登录）并获得授权（拥有权限）来使用资源。详细可以查看AWSIAM文档[3]。
与聘请一个保安在大厦门口相似，企业的应用程序接入IAM服务后，就可以“高枕无忧”，IAM会帮你控制谁有访问应用的权限。
3.IDaaS身份即服务来到本文的主角，身份即服务：IdentityasaService。
Identity就是IAM中的身份概念，asaService就是开篇介绍的SaaS。
IDaaS实际上就是一个基于SaaS模式的IAM解决方案，也就是云上的身份和访问管理服务，完全由受信任的第三方云服务厂商托管和管理。它允许企业使用单点登录、身份验证和访问控制来提供对任意接入的已实现标准协议应用的安全访问。
根据IDaaS厂商提供的功能，某种程度下，你甚至可以认为IDaaS就是IAM。
国内目前了解到的IDaaS厂商有，腾讯云IDaaS[4]，阿里云应用身份服务IDaaS[5]，Authing[6]。在云计算、云原生领域，很多时候想要了解一个产品，其实可以去上述三家企业官网看看，多参考参考他们的现成方案。点击查看Authing开发者文档
二、IDaaS的五统能力IDaaS的功能可以合称为5A能力[7]：Account、Authentication、Authorization、Application、Audit。
但我愿称其为五统能力：
1.统一账号管理Account模块的管理，这块容易理解。你想最基本的一块，应用程序要想实现单点登陆的话，
单点登录（SingleSignOn），简称为SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
A系统使用了user1登录成功后，B系统随之也以user1的身份登录成功了。例如淘宝taobao.com和天猫tmall.com两个站点。
那其账号是不是必须得统一放在一处（IDaaS）进行会话管理。
不过通常由于业务需要，应用系统和IDaaS还得做一次账号同步（SCIM/LDAP方式）。
2.统一身份认证身份认证叫做Authentication。更形象化就是指你在应用上通过输入账号密码、验证码或扫码等方式进行登录的这个过程。
而这个过程IDaaS所使用的认证协议会帮你做了，而且把登录页面都给做了，直接喂到你嘴里，你应用只需要重定向过来即可。
身份认证协议有很多种：OIDC/SAML等。下文我会再着重讲述OIDC协议。
3.统一授权管理Authorization是授权，切忌别和认证Authentication混淆。
授权是指客户端经过身份认证成功后，能够以有限的权限去访问服务端资源的一种机制。
IDaaS的授权架构一般会选用基于角色的权限访问控制（RBAC）。
常用的授权模式的话有基于OAuth2.0框架的授权码模式，这部分我也会在下文的OIDC章节重点讲诉。
4.统一应用管理Application应用包括企业接入进来的自身应用以及IDaaS所提供的一些可选模板应用（如GitLab、Grafana等）。
IDaaS自身提供统一标准规范，对应用统一管理，例如可以控制应用是否支持单点登录，控制应用的可访问成员等。
5.统一审计管理Audit审计，没什么好讲的，业务角度，代码埋点，Webhook等方式记录下应用和用户相关的操作日志，便于管理员分析系统的日常操作与安全事件数据。
三、OIDC身份认证协议接下来将进入本文核心内容，讲述IDaaS背后支撑着认证和授权能力的基石：OAuth2.0和OIDC协议。
1.OAuth2.0OAuth即OpenAuthorization，开放授权。
OAuth2.0（RFC6749[8]）是一个授权标准协议，可以使第三方应用获得对资源服务的有限访问。
根据OAuth2.0协议规范，定义了四个角色：
资源所有者（ResourceOwner）：能够授予对受保护资源访问权限的实体。例如应用的用户是资源的所有者，可以授权其他人访问他的资源。当资源所有者是一个人时，它被称为最终用户。
资源服务器（ResourceServer）：存储受保护资源的服务器，能够接受并使用访问令牌来响应受保护的资源请求。就是资源服务器接受AccessToken，然后验证它拥有的权限，最后返回对应的资源。这个资源服务器一般是应用本身。
授权服务器（AuthorisationServer）：服务器向客户端（即应用）颁发访问令牌来验证资源所有者并获得授权。即负责颁发AccessToken的服务器，例如IDaaS就是一个授权服务器。
客户端（Client）：需要获取访问令牌以访问资源服务器的应用。经过授权后，授权服务器为客户端颁发AccessToken。后续客户端可以携带这个AccessToken到资源服务器那访问用户的资源。
在OAuth2.0中一个应用可能既是ResourceServer，也是Client，具体是什么角色，取决于应用工作的场景。
概念可能有点难嚼，还请慢咽。
这四个角色一直在围绕着一个叫AccessToken的东西在转圈圈。
AccessToken也就是访问令牌，它用于允许应用访问一个资源API。用户认证授权成功后，授权服务器会签发AccessToken给应用。应用后续需要携带AccessToken访问资源API，资源服务API会检验AccessToken是否有权限访问，从而决定是否返回对应资源。
而AccessToken本质上只是一串随机字符串，并不能从中获取到任何信息，检验AccessToken的步骤还需要资源服务器将它转发到授权服务器上进行解析验证。
了解完AccessToken之后，我们来关注一下客户端调用方是如何获取到它的，也就是授权模式的选择。
授权码模式（AuthorizationCode）：适用于具有完整前后端的传统Web应用以及移动或桌面端应用。
隐式模式（Implicit）：适用于没有后端的基于浏览器（JavaScript）的纯前端应用。
密码模式（ResourceOwnerPasswordCredentials）：适用于资源服务器和客户端之间高度信任的情况下，例如自家应用使用自家的资源。
客户端凭证模式（ClientCredentials）：适用于没有前端参与，纯后端交互的情况，期间没有用户的参与，客户端自己就是资源所有者。......
我们重点关注授权码模式和客户端凭证模式，这两个是最常用的。
先看授权码模式，也叫code换token模式，我们以StackOverflow使用GitHub登录为例（在这个过程中StackOverflow是客户端，GitHub是资源服务器，提供邮箱头像等资源信息，同时GitHub也是授权服务器，会颁发token给客户端）。
第一步，点击登录后需要跳转到授权服务器地址，即GitHub的地址，并且必须在URL上携带client_id和redirect_uri以及scope等信息。
client_id可以让GitHub知道是哪个客户端在请求资源，这里的01b478c0264a1fbd7183就是StackOverflow在GitHub中注册的客户端ID；
redirect_uri是授权成功或失败后的回调地址；
response_type=code表示使用授权码模式授权；
scope表示应用正在请求哪些权限；
state是一个随机字符串用来防止CSRF攻击。
继续第二步，当我们点击授权按钮后，这时授权服务器即GitHub会将浏览器重定向到第一步的redirect_uri参数指定的网址。并且跳转时，会携带一个授权码code参数（由GitHub后台生成的）以及state参数。
第三步，由于浏览器触发请求了redirect_uri，所以StackOverflow网站后台可以接收到请求并拿到授权码code和state，这时就可以将state和第一步生成的state对比以防止CSRF和其他相关攻击。
第四步，StackOverflow可以拿着client_id、client_secret、code跟GitHub交换令牌，GitHub收到请求以后就会校验code并颁发访问令牌（code是有过期时间的，并且是一次性的）。
Ruby//RequestPOSTcode=1efc47a278d10a04f88e&client_id=01b478c0264a1fbd7183&client_secret=xxxxxx//ResponseAccept:application/json{"access_token":"gho_16C7e42F292c6912E7710c838347Ae178B4a","scope":"user:email","token_type":"bearer"}最后第五步，StackOverflow使用GitHub颁发的访问令牌跟GitHub获取到所需的资源（用户邮箱地址），然后就走自己的业务流程了，一般就是重定向回首页。
完整的流程可以看GitHub的CreatinganOAuthAppDocs[9]。
另一个客户端凭证模式就相对简单了，毕竟只是纯后端交互。
例如，一个B应用拥有很多photo资源，即B为资源服务器（假设同时也是授权服务器），A客户端想要获取B的photo资源。
第一步，A应用直接使用client_id和client_secret向B申请资源。
Groovyhttps://b.com/oauth/token?grant_type=client_credentials&scope=photo&client_id=xxx&client_secret=xxxresponse_type=client_credentials表示使用客户端凭证模式授权。
第二步，B作为授权服务器验证A客户端的client_id和client_secret是否合法，然后颁发访问令牌。
第三步，A客户端携带访问令牌向B资源服务器获取photo资源。
这期间并没有用户的参与，A客户端自己就相当于一个“用户”。
2.OpenIDConnect讲完OAuth2.0授权，来到OIDC认证协议。
如标题，OIDC全称是OpenIDConnect[10]，
是一个基于OAuth2.0的认证+授权（OAuth2.0提供的能力）协议。
OIDC可以理解为OAuth2.0的超集，在OAuth2.0之上实现了更多的标准，例如定义了一系列的EndPoint。还有一些规范诸如SessionManagement[11]，Front-ChannelLogout[12]，Back-ChannelLogout[13]等。
OIDC之所以有认证的功能，是因为在OAuth2.0颁发AccessToken的基础上，多颁发了一个IDToken（用户的身份凭证），和AccessToken是一个随机字符串不同的是，IDToken是一个JWTToken。
IDToken自身包含了一些用户的基本信息，而且由于JWT的防篡改性，让客户端不需要再向授权服务器进行身份验证，就能直接用IDToken来进行身份验证。即使IDToken包含的用户信息不够，也可以调用OIDC定义的UserInfoEndPoint（用户信息接口）来获取更多的用户信息。
OIDC协议定义的名词和OAuth2.0协议定义的稍微有些出入：
OpenIDProvider，简称OP：相当于OAuth2.0中的授权服务器，除了负责颁发AccessToken，还会颁发IDToken。例如IDaaS就是一个OP。
RelyingParty，简称RP：代指OAuth2.0中的客户端。
EndUser，简称EU：即用户。
最后，OIDC的授权流程与OAuth2.0是一样的，主要区别在于OIDC授权流程中会额外返回IDToken。
IDaaS的认证和授权使用了OIDC/OAuth2.0。说白了，要搭建IDaaS得先搭建一个授权服务器OpenIDProvider（更多时候称之为OIDCProvider）。
但即便完全了解OIDC协议，自行实现一套完整的OIDCProvider依旧十分繁琐，好在云原生环境下孕育出了很多优秀的项目。本文会简单介绍一下Go语言生态下的dexidp/dex和ory/hydra，感兴趣的可以自行到其官网详细了解。
1.dexidp/dexDex[14]作为CNCF的一个sandbox项目，是一个具有可插拔连接器的OIDC和OAuth2.0提供商。
它通过”连接器“的身份来充当其他身份提供商的门户，可以将身份验证推送到LDAP服务器、SAML提供商或GitHub、Google和ActiveDirectory等其他一些成熟的身份提供商中进行验证。客户端只需写一次认证逻辑就可以与Dex对接，然后Dex来处理特定后端的协议。
ORYHydra[15]是一个OAuth2.0和OpenIDConnect提供者。
特别一说的是Hydra所实现的OAuth2.0协议并不依赖Go标准库提供的，而是自实现的fosite[16]。
另外ORYHydra还提供了一个5分钟的快速搭建教程。
身份行业正全面朝着现代化身份标准发展，零信任的网络安全模型、基于区块链技术的去中心化身份认证、基于物联网（IoT）的身份认证、隐私及法规问题的解决方案等都是目前身份行业所面临的挑战和趋势。
IDaaS作为现代身份之称，正是为了支持当前和未来的变化才诞生的。借助IDaaS，可以轻松地连接到您的组织，为您提供创新未来。
而Authing正是这样一个优秀的IDaaS提供商。作为国内首款以开发者为中心的全场景身份云产品，集成了所有主流身份认证协议，为企业和开发者提供完善安全的用户认证和访问管理服务。
主要功能包括：单点登录、用户分析、扫码登录、多因素认证、行为审计、风险控制、跨平台设备管理、IoT身份认证等；兼容国际各类标准协议：OAuth2.0、OIDC、SAML、AD/LDAP、WS-Fed、JWT等；此外还有基于函数计算可以无*拓展Authing能力的Pipeline。支持云交付和私有化部署方式，帮助企业和开发者千倍级提升生产效率。
不管是ToB、ToE的企业场景，还是ToC的终端用户场景，Authing都可以：大幅降低运营成本，提升内部管理效率；提升用户体验，提升用户运营能力。
参考资料
[1]交付模式对比图:https://www.redhat.com/zh/topics/cloud-computing/what-is-saas
[2]PizzaasaService:https://m.oursky.com/saas-paas-and-iaas-explained-in-one-graphic-d56c3e6f4606
[3]AWSIAM文档:https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/introction.html
[4]腾讯云IDaaS:https://cloud.tencent.com/proct/tcid
[5]阿里云应用身份服务IDaaS:https://www.aliyun.com/proct/idaas
[6]Authing:https://www.authing.cn/
[7]5A能力:https://help.aliyun.com/document_detail/167902.html
[8]RFC6749:https://datatracker.ietf.org/doc/html/rfc6749
[9]CreatinganOAuthAppDocs:https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app
[10]OpenIDConnect:https://openid.net/specs/openid-connect-core-1_0.html
[11]SessionManagement:https://openid.net/specs/openid-connect-session-1_0.html
[12]Front-ChannelLogout:https://openid.net/specs/openid-connect-frontchannel-1_0.html
[13]Back-ChannelLogout:https://openid.net/specs/openid-connect-backchannel-1_0.html
[14]Dex:https://dexidp.io/
[15]ORYHydra:https://www.ory.sh/hydra/docs/next/
[16]fosite:https://github.com/ory/fosite
