webapi 获取oidc的信息_webapi call another webapi - CSDN
精华内容
参与话题
  • 在上一篇[认证授权] 4.OIDC(OpenId Connect)身份认证授权(核心部分)中解释了OIDC的核心部分的功能,即OIDC如何提供id token来用于认证。由于OIDC是一个协议族,如果只是简单的只关注其核心部分其实是不足以搭建...

    在上一篇[认证授权] 4.OIDC(OpenId Connect)身份认证授权(核心部分)中解释了OIDC的核心部分的功能,即OIDC如何提供id token来用于认证。由于OIDC是一个协议族,如果只是简单的只关注其核心部分其实是不足以搭建一个完整的OIDC服务的。本篇则解释下OIDC中比较常用的几个相关扩展协议,可以说是搭建OIDC服务必备的几个扩展协议(在上一篇中有提到这几个协议规范):

    1. Discovery:可选。发现服务,使客户端可以动态的获取OIDC服务相关的元数据描述信息(比如支持那些规范,接口地址是什么等等)。
    2. OAuth 2.0 Multiple Response Types :可选。针对OAuth2的扩展,提供几个新的response_type。
    3. OAuth 2.0 Form Post Response Mode:可选。针对OAuth2的扩展,OAuth2回传信息给客户端是通过URL的querystring和fragment这两种方式,这个扩展标准提供了一基于form表单的形式把数据post给客户端的机制。
    4. 会话管理:Session Management :可选。Session管理,用于规范OIDC服务如何管理Session信息;Front-Channel Logout:可选。基于前端的注销机制。

    1 OIDC Discovery 规范

    顾名思义,Discovery定义了一个服务发现的规范,它定义了一个api( /.well-known/openid-configuration ),这个api返回一个json数据结构,其中包含了一些OIDC中提供的服务以及其支持情况的描述信息,这样可以使得oidc服务的RP可以不再硬编码OIDC服务接口信息。这个api返回的示例信息如下(这里面只是一部分,更完整的信息在官方的规范中有详细的描述和解释说明:http://openid.net/specs/openid-connect-discovery-1_0.html):

    相信大家都看得懂的,它包含有授权的url,获取token的url,注销token的url,以及其对OIDC的扩展功能支持的情况等等信息,这里就不再详细解释每一项了。

    2 OAuth2 扩展:Multiple Response Types

    在本系列的第一篇博客[认证授权] 1.OAuth2授权中解释OAuth2的授权请求的时候,其请求参数中有一个 response_type 的参数,其允许的值有 code 和 token 两个,在这两个的基础上,OIDC增加了一个新值 id_token (详细信息定义在http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html):

    1. code:oauth2定义的。用于获取authorization_code。
    2. token:oauth2定义的。用户获取access_token。
    3. id_token:OIDC定义的。用户获取id_token。

    至此OIDC是支持三种类型的response_type的,不但如此,OIDC还允许了可以组合这三种类型,即在一个response_type中包含多个值(空格分隔)。比如当参数是这样的时候 response_type=id_token token ,OIDC服务就会把access_token和id_token一并给到调用方。OIDC对这些类型的支持情况体现在上面提到的Discovery服务中返回的response_types_supported字段中:

    3 OAuth2 扩展:Form Post Response Mode

    在oauth2的授权码流程中,当response_type设置为code的时候,oauth2的授权服务会把authorization_code通过url的query部分传递给调用方,比如这样“https://client.lnh.dev/oauth2-callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz”。

    在oauth2的隐式授权流程中,当response_type设置为token的时候,oauth2的授权服务会直接把access_token通过url的fragment部分传递给调用方,比如这样“http://client.lnh.dev/oauth2-callback#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&expires_in=3600”;

    在oauth2中,上面的两种情况是其默认行为,并没有通过参数来显示的控制。OIDC在保持oauth2的默认行为的基础上,增加了一个名为response_mode的参数,并且增加了一种通过form表单传递信息的方式,即form_post(详细信息定义在http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html)。OIDC服务对这个扩展的支持情况体现在上面提到的Discovery服务中返回的response_modes_supported字段中:

    当reponse_mode设置为form_post的时候,OIDC则会返回如下的信息:

      <html>
       <head><title>Submit This Form</title></head>
       <body onload="javascript:document.forms[0].submit()">
        <form method="post" action="https://client.lnh.dev/oidc-callback">
          <input type="hidden" name="state"
           value="DcP7csa3hMlvybERqcieLHrRzKBra"/>
          <input type="hidden" name="id_token"
           value="eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiw
             iYXVkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLC
             Jpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5M
             DMxMTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1B
             SnllRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0F
             NTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2Mz
             kwMDg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjlyulRSNrru1ySZs2qwqq
             wwq-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEHII-_fk
             IufbGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcq
             XVEKhtPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_h
             nrQ5IKXuNsQ1g9ccT5DMtZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc
             0uVAwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA"/>
        </form>
       </body>
      </html>

    这是一个会在html加载完毕后,通过一个自动提交的form表单,把id_token,access_token,authorization_code或者其他的相关数据POST到调用方指定的回调地址上。

    4 OIDC 会话管理

    综合上篇提到的idtoken和前面的discovery服务以及针对oauth2的扩展,则可以让OIDC服务的RP完成用户认证的过程。那么如何主动的撤销这个认证呢(也就是我们常说的退出登录)?总结来说就是其认证的会话管理,OIDC单独定义了3个独立的规范来完成这件事情:

    1. Session Management :可选。Session管理,用于规范OIDC服务如何管理Session信息。
    2. Front-Channel Logout:可选。基于前端的注销机制。
    3. Back-Channel Logout:可选。基于后端的注销机制。

    其中Session Management是OIDC服务自身管理会话的机制;Back-Channel Logout则是定义在纯后端服务之间的一种注销机制,应用场景不多,这里也不详细解释了。这里重点关注一下Front-Channel Logout这个规范(http://openid.net/specs/openid-connect-frontchannel-1_0.html),它的使用最为广泛,其工作的具体的流程如下(结合Session Management规范)

     

    在上图中的2和3属于session management这个规范的一部。其中第2步中,odic的退出登录的地址是通过Discovery服务中返回的end_session_endpoint字段提供的RP的。其中还有一个check_session_iframe字段则是供纯前端的js应用来检查oidc的登录状态用的。

    4567这四步则是属于front-channel logout规范的一部分,OIDC服务的支持情况在Discovery服务中也有对应的字段描述:

    4567这一部分中重点有两个信息:

    1. RP退出登录的URL地址(这个在RP注册的时候会提供给OIDC服务);
    2. URL中的sessionid这个参数,这个参数一般是会包含在idtoken中给到OIDC客户端,或者在认证完成的时候以一个独立的sessionid的参数给到OIDC客户端,通常来讲都是会直接把它包含在IDToken中以防止被篡改。

    5 总结

    本篇博客介绍了OIDC的发现服务,OAuth2的两个扩展规范,以及OIDC管理会话的机制。至此则可以构成一个完整的认证和退出的流程。其中有一点需要特别注意,这个流程中用到的token是OIDC定义的IDTokenIDTokenIDToken(重要要的事情说三遍),而不是OAuth2中定义的Access Token,千万不要混淆这两者,它们是有着本质的区别的(这一点在[认证授权] 3.基于OAuth2的认证(译)[认证授权] 4.OIDC(OpenId Connect)身份认证授权(核心部分)中都有解释)。

    6 Example

    笔者基于IdentityServer3和IdentitySever4(两者都是基于OIDC的一个.NET版本的开源实现)写的一个集成SSO,API访问授权控制,GIthub,QQ登录(作为IDP)的demo:https://github.com/linianhui/oidc.example

    参考

    oidc : http://openid.net/connect/

    oidc - discovery :http://openid.net/specs/openid-connect-discovery-1_0.html

    oauth2 - multiple-response-types :http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

    oauth2 - form-post-response-mode :http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

    oidc - session-menagement :http://openid.net/specs/openid-connect-session-1_0.html

    oidc - front-channel-logout :http://openid.net/specs/openid-connect-frontchannel-1_0.html

     

    展开全文
  • 在上一篇基于OIDC的SSO的中涉及到了4个Web站点: oidc-server.dev:利用oidc实现的统一认证和授权中心,SSO站点。 oidc-client-hybrid.dev:oidc的一个客户端,采用hybrid模式。 oidc-client-implicit....

    在上一篇基于OIDC的SSO的中涉及到了4个Web站点:

    1. oidc-server.dev:利用oidc实现的统一认证和授权中心,SSO站点。

    2. oidc-client-hybrid.dev:oidc的一个客户端,采用hybrid模式。

    3. oidc-client-implicit.dev:odic的另一个客户端,采用implicit模式。

    4. oidc-client-js.dev:oidc的又一个客户端,采用implicit模式,纯静态网站,只有js和html,无服务端代码。

    其中hybrid和implicit这两个站点都是具有在服务端执行代码的能力的(1,登录需要在服务端做跳转;2,登录状态写入cookie;3,通过服务端的接口接收被动的退出通知)。而js这个客户端则是一个纯粹的静态网站,那么它是如何处理登录和退出的呢?

    oidc-client-js.dev这个web站点对应的代码位于web.oidc.client.js这个文件夹中(https://github.com/linianhui/oidc.example/tree/master/src/web.oidc.client.js):

    640?wx_fmt=png&wxfrom=5&wx_lazy=1

    JS Client 登录

    我们知道在浏览器中的JS是可以直接进行页面跳转的,oidc的js客户端就是利用这个来直接构造认证请求的URL,然后进行登录跳转的(我们这里使用的是oidc-client.js这个开源的js库来处理oidc规范相关的一下操作的)。下图是打开oidc-client-js.dev后的页面:

    0?wx_fmt=png

    JS Client 直接发起认证请求

    我们点击下Login。

    0?wx_fmt=png

    可以看到Client这边在对oidc-server.dev这个站点发起了2个请求之后就直接构造了一个认证请求的URL,并交给浏览器去发起了请求。

    1. /account/js:我自己扩展的,后面介绍其用途,目前暂时忽略它。

    2. /.well-known/openid-configuration:这个是之前介绍到的OIDC提供的Discovery服务,Client需要从这个服务返回的JSON中获取认证请求的接口地址以及其他的信息。

    认证请求这里面包含的参数和上篇中的信息并没有什么差别,这里就不介绍了。

    OIDC-Server 通过URL的#把数据传递给JS Client

    浏览器会重定向到登录页面,我们登录一下,登录成功后会跳转上面所填写的redriect_uri参数指定的URL,并使用URL的#部分携带认证后的信息:

    http://oidc-client-js.dev/oidc/login-callback.html#id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6ImI2MmE2YTVlZjNiNGJmOTlhNWU3M2FkZmI1OTQ3NjRjIiwidHlwIjoiSldUIn0.eyJuYmYiOjE1MTE3NTEyMjgsImV4cCI6MTUxMTc1MTUyOCwiaXNzIjoiaHR0cDovL29pZGMtc2VydmVyLmRldiIsImF1ZCI6ImpzLWNsaWVudCIsIm5vbmNlIjoiZGU5NGI1NGMzNDk1NGFjMjg0Y2I0NzlhY2M5ZGMxMjMiLCJpYXQiOjE1MTE3NTEyMjgsImF0X2hhc2giOiJ1QnJhckVLOHk4elhwR0pJOG1BaE1nIiwic2lkIjoiMWQ2ZWQwYWI0ZjdhNzI2MDUxMzBiYjBkYjNiOTdkY2MiLCJzdWIiOiIwMDAwMDEiLCJhdXRoX3RpbWUiOjE1MTE3NTEyMjgsImlkcCI6ImxvY2FsIiwiYW1yIjpbImV4dGVybmFsIl19.EUMT0R34OKDuE8AESEnRAASoRCP2NCAy7EEkMdM9vBwfz8BGnrCGXiDnKoUgbw3qK8ekoiwhSed6qE-Xh5QqnnwQTOc_D0nucbA3CVqKDhc9TFonEHoU60ETbX0i70bbOThZeoJdto9CkILbcewk2SLgfCQXZzsKERm6AS7m9LUN7cGjQJQm6Ht5DpIgjFu7s9V7qnUfu7hjvI51zPmYgJwLtvCXb9vAxXy17oBrVTmYunDLETRnfj9UXcsSROOW6Ac6sKSLOtFkY5ElZuIa5Za_1GJFDaoYyZwFT53WWBO9-LBdIHd8Cqx5fyw8tlpT3qmdwf0scSr256sVXykGQw&access_token=eyJhbGciOiJSUzI1NiIsImtpZCI6ImI2MmE2YTVlZjNiNGJmOTlhNWU3M2FkZmI1OTQ3NjRjIiwidHlwIjoiSldUIn0.eyJuYmYiOjE1MTE3NTEyMjgsImV4cCI6MTUxMTc1NDgyOCwiaXNzIjoiaHR0cDovL29pZGMtc2VydmVyLmRldiIsImF1ZCI6WyJodHRwOi8vb2lkYy1zZXJ2ZXIuZGV2L3Jlc291cmNlcyIsIm15LWFwaSJdLCJjbGllbnRfaWQiOiJqcy1jbGllbnQiLCJzdWIiOiIwMDAwMDEiLCJhdXRoX3RpbWUiOjE1MTE3NTEyMjgsImlkcCI6ImxvY2FsIiwic2NvcGUiOlsib3BlbmlkIiwicHJvZmlsZSIsIm15LWFwaSJdLCJhbXIiOlsiZXh0ZXJuYWwiXX0.BU65olTuhLSlyFHyRzSHKUaFw5v5qMg7qmutl3LCel0gtjD9ky9cyD3rUNNAkalVcHXg7znN_F2JB71ape9mSD_L66H8pTTwaiMTxbPz9_HMEz9w6GgmOrjMGP8unIpCOKom1DV4EiSQoDe8P30oh2mwmA5SLvZixlAln3_ycArTd7440SCUrUvnEa1CJyl-K-kkLvLyl3TRo6bDE-H47-AzHq1NtA22cwleVXNxUtOsMHk1Nsa2tOFW6B4t3fAvo_MWx2BFkJMBToy4ArepLXSaN5CQQxH8na1Havll3Ly3c9GOslNsm1krMvx9GYdFR6DgjoDvNbaVDkLdmO2T_w&token_type=Bearer&expires_in=3600&scope=openid%20profile%20my-api&state=96af404863044d49b6e14a5827862538&session_state=C33U-BpeYNeLhWhUuKLfup18cjKkKX54yCdL2fUOtV0.5ec877a6108fde6ad04e774a770d7ee1

    这里相比上一篇中返回的信息多了一个access_token是因为我们的认证请求的response_type设置为了“id_token token”,故而oidc-server.dev把id_token和access_token一并给到了客户端。

    JS Client 解析#中的数据,保存自己的登录状态

    解析#后面的数据也是通过oidc-client.js 这个开源的库来实现的。解析后的数据呈现在页面上是如下这个样子。

    0?wx_fmt=png

    其中登录后用户的信息保存在浏览器的SessionStorage中:

    0?wx_fmt=png

    JS Client 主动登出

    退出操作和其他类型的客户端一致,也是先清理自己保存的Session Storage,然后通知oidc-server.dev进行登出,这里就不详细解释了。

    JS Client 被动登出

    我们知道在SSO中,除了自身主动退出登录之外,还有其他的Client退出的时候,这里的JS Client也要被动的登出。由于JS Client没有服务端在服务端执行代码的能力,其登录状态也是保存在客户端这边的,那么它就没办法接收像其他的客户端一样接收到登出的通知了。这个时候就需要客户端自己主动去oidc-server.dev检查登录状态了。这一部分在OIDC中也有标准规范,体现在OIDC的Discovery服务中的check_session_iframe字段中。

    0?wx_fmt=png

    这个地址checksession的地址是oidc-server.dev的地址,那么这个地址返回的html页面中,就可以通过js来检查去存储在cookie中的session信息的是否发生变化。然后通过H5中新增的postMessage来把这种变化传递给js client这边。js client再去检查一下是否已经登出了。如果已经登出,则会清理自身的登录状态来完成被动的登出操作。

    比如下图。我再oidc-client-implicit.dev点击登出的时候,会触发oidc-server.dev清理自己的cookie,然后js-client中使用check_session_iframe这个隐藏的iframe可以检测到这种变化,从而使得js-client可以得知用户已经再其他的client退出登录。

    0?wx_fmt=png

    自动登录

    前面提到JS Client会加载一个oidc-server.dev/account/js的JS脚本文件,这个是我自己扩展出来的一个脚本。它会在这个纯静态的网站在一开使打开的时候告诉客户端oidc-server.dev是否已经登录了。

    0?wx_fmt=png

    然后静态的网站就可以利用account这个变量来决定是否再打开网站的时候就自动去登录(由于其他站点已经登陆过了,那么oidc-server.dev站点会自动携带登录后的信息的再次跳转回来)。

    0?wx_fmt=png

    读者可以打开浏览器,先打开oidc-client-implicit.dev这个站点并且登录,然后再打开oidc-client-js.dev这个站点的时候,就会发现它会自动的登录成功了。

    总结

     本篇介绍了再浏览器中运行的纯静态的HTML网站使如何使用OIDC服务进行单点登录,统一登出,登录状态监控,以及附加的如何让JS Client自动登录的原理。这里所使用的例子使传统的HTML+JS的结构。如果你使采用的Vue,Angular或者React的这类前端框架的话,那么其本质上的原理也是完全一样的,因为不管使采用的什么框架,最终输出给浏览器的还是HTML+JS而已。

    参考

    本文源代码:https://github.com/linianhui/oidc.example

    oidc-client.js:https://github.com/IdentityModel/oidc-client-js

    相关文章:

    原文:http://www.cnblogs.com/linianhui/p/oidc-in-action-sso-with-js-client.html


    .NET社区新闻,深度好文,欢迎访问公众号文章汇总 http://www.csharpkit.com

    640?wx_fmt=jpeg

    展开全文
  • OIDC(OpenId Connect)身份认证

    万次阅读 2019-06-23 23:34:25
    1 什么是OIDC? 看一下官方的介绍(http://openid.net/connect/): OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-...

    1 什么是OIDC?

    看一下官方的介绍(http://openid.net/connect/):

    OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

    OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.

    简单来说:OIDC是OpenID Connect的简称,OIDC=(Identity, Authentication) + OAuth 2.0。它在OAuth2上构建了一个身份层,是一个基于OAuth2协议的身份认证标准协议。我们都知道OAuth2是一个授权协议,它无法提供完善的身份认证功能(关于这一点请参考[认证授权] 3.基于OAuth2的认证(译)),OIDC使用OAuth2的授权服务器来为第三方客户端提供用户的身份认证,并把对应的身份认证信息传递给客户端,且可以适用于各种类型的客户端(比如服务端应用,移动APP,JS应用),且完全兼容OAuth2,也就是说你搭建了一个OIDC的服务后,也可以当作一个OAuth2的服务来用。应用场景如图:

    OIDC已经有很多的企业在使用,比如Google的账号认证授权体系Microsoft的账号体系也部署了OIDC,当然这些企业有的也是OIDC背后的推动者。除了这些之外,有很多各个语言版本的开源服务端组件,客户端组件等等(http://openid.net/developers/certified/);

    理解OIDC的前提是需要理解OAuth2,这里假设大家都有OAuth2的基础,不清楚的可以先阅读本系列的前几篇OAuth2的文章。

    2 OIDC 协议族

    OIDC本身是有多个规范构成,其中包含一个核心的规范,多个可选支持的规范来提供扩展支持,简单的来看一下:

    1. Core:必选。定义OIDC的核心功能,在OAuth 2.0之上构建身份认证,以及如何使用Claims来传递用户的信息。
    2. Discovery:可选。发现服务,使客户端可以动态的获取OIDC服务相关的元数据描述信息(比如支持那些规范,接口地址是什么等等)。
    3. Dynamic Registration :可选。动态注册服务,使客户端可以动态的注册到OIDC的OP(这个缩写后面会解释)。
    4. OAuth 2.0 Multiple Response Types :可选。针对OAuth2的扩展,提供几个新的response_type。
    5. OAuth 2.0 Form Post Response Mode:可选。针对OAuth2的扩展,OAuth2回传信息给客户端是通过URL的querystring和fragment这两种方式,这个扩展标准提供了一基于form表单的形式把数据post给客户端的机制。
    6. Session Management :可选。Session管理,用于规范OIDC服务如何管理Session信息。
    7. Front-Channel Logout:可选。基于前端的注销机制,使得RP(这个缩写后面会解释)可以不使用OP的iframe来退出。
    8. Back-Channel Logout:可选。基于后端的注销机制,定义了RP和OP直接如何通信来完成注销。

    除了上面这8个之外,还有其他的正在制定中的扩展。看起来是挺多的,不要被吓到,其实并不是很复杂,除了Core核心规范内容多一点之外,另外7个都是很简单且简短的规范,另外Core是基于OAuth2的,也就是说其中很多东西在复用OAuth2,所以说你理解了OAuth2之后,OIDC就是非常容易理解的了,我们这里就只关注OIDC引入了哪些新的东西(Core,其余7个可选规范不做介绍,但是可能会提及到)。千言万语都不如一张图,没图你说个***。

    上图是官方给出的一个OIDC组成结构图,我们暂时只关注Core的部分,其他的部分了解是什么东西就可以了,当作黑盒来用。就像当初的AJAX一样,它其实并不是一个新的技术,而是结合很多已有的技术,按照规范的方式组合起来,就是AJAX。同理,OIDC也不是新技术,它主要是借鉴OpenId的身份标识,OAuth2的授权和JWT包装数据的方式,把这些技术融合在一起就是OIDC。

    3 OIDC 核心概念

    OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题;OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。OIDC的核心在于在OAuth2的授权流程中,一并提供用户的身份认证信息(ID Token)给到第三方客户端,ID Token使用JWT格式来包装,得益于JWT(JSON Web Token)的自包含性,紧凑性以及防篡改机制,使得ID Token可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了UserInfo的接口,用户获取用户的更完整的信息。

    3.1 OIDC 主要术语

    主要的术语以及概念介绍(完整术语参见http://openid.net/specs/openid-connect-core-1_0.html#Terminology):

    1. EU:End User:一个人类用户。
    2. RP:Relying Party ,用来代指OAuth2中的受信任的客户端,身份认证和授权信息的消费方;
    3. OP:OpenID Provider,有能力提供EU认证的服务(比如OAuth2中的授权服务),用来为RP提供EU的身份认证信息;
    4. ID Token:JWT格式的数据,包含EU身份认证的信息。
    5. UserInfo Endpoint:用户信息接口(受OAuth2保护),当RP使用Access Token访问时,返回授权用户的信息,此接口必须使用HTTPS。

    3.2 OIDC 工作流程

    从抽象的角度来看,OIDC的流程由以下5个步骤构成:

    1. RP发送一个认证请求给OP;
    2. OP对EU进行身份认证,然后提供授权;
    3. OP把ID Token和Access Token(需要的话)返回给RP;
    4. RP使用Access Token发送一个请求UserInfo EndPoint;
    5. UserInfo EndPoint返回EU的Claims。

    上图取自Core规范文档,其中AuthN=Authentication,表示认证;AuthZ=Authorization,代表授权。注意这里面RP发往OP的请求,是属于Authentication类型的请求,虽然在OIDC中是复用OAuth2的Authorization请求通道,但是用途是不一样的,且OIDC的AuthN请求中scope参数必须要有一个值为的openid的参数(后面会详细介绍AuthN请求所需的参数),用来区分这是一个OIDC的Authentication请求,而不是OAuth2的Authorization请求。

    3.3 ID Token

    上面提到过OIDC对OAuth2最主要的扩展就是提供了ID Token。ID Token是一个安全令牌,是一个授权服务器提供的包含用户信息(由一组Cliams构成以及其他辅助的Cliams)的JWT格式的数据结构。ID Token的主要构成部分如下(使用OAuth2流程的OIDC)。

    1. iss = Issuer Identifier:必须。提供认证信息者的唯一标识。一般是一个https的url(不包含querystring和fragment部分)。
    2. sub = Subject Identifier:必须。iss提供的EU的标识,在iss范围内唯一。它会被RP用来标识唯一的用户。最长为255个ASCII个字符。
    3. aud = Audience(s):必须。标识ID Token的受众。必须包含OAuth2的client_id。
    4. exp = Expiration time:必须。过期时间,超过此时间的ID Token会作废不再被验证通过。
    5. iat = Issued At Time:必须。JWT的构建的时间。
    6. auth_time = AuthenticationTime:EU完成认证的时间。如果RP发送AuthN请求的时候携带max_age的参数,则此Claim是必须的。
    7. nonce:RP发送请求的时候提供的随机字符串,用来减缓重放攻击,也可以来关联ID Token和RP本身的Session信息。
    8. acr = Authentication Context Class Reference:可选。表示一个认证上下文引用值,可以用来标识认证上下文类。
    9. amr = Authentication Methods References:可选。表示一组认证方法。
    10. azp = Authorized party:可选。结合aud使用。只有在被认证的一方和受众(aud)不一致时才使用此值,一般情况下很少使用。

    ID Token通常情况下还会包含其他的Claims(毕竟上述claim中只有sub是和EU相关的,这在一般情况下是不够的,必须还需要EU的用户名,头像等其他的资料,OIDC提供了一组公共的cliams,请移步这里http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)。另外ID Token必须使用JWS进行签名和JWE加密,从而提供认证的完整性、不可否认性以及可选的保密性。一个ID Token的例子如下:

     1 {
     2    "iss": "https://server.example.com",
     3    "sub": "24400320",
     4    "aud": "s6BhdRkqt3",
     5    "nonce": "n-0S6_WzA2Mj",
     6    "exp": 1311281970,
     7    "iat": 1311280970,
     8    "auth_time": 1311280969,
     9    "acr": "urn:mace:incommon:iap:silver"
    10   }

    3.4 认证

    解释完了ID Token是什么,下面就看一下OIDC如何获取到ID Token,因为OIDC基于OAuth2,所以OIDC的认证流程主要是由OAuth2的几种授权流程延伸而来的,有以下3种:

    1. Authorization Code Flow:使用OAuth2的授权码来换取Id Token和Access Token。
    2. Implicit Flow:使用OAuth2的Implicit流程获取Id Token和Access Token。
    3. Hybrid Flow:混合Authorization Code Flow+Implici Flow。

    这里有个小问题大家可以思考下,OAuth2中还有基于Resource Owner Password Credentials Grant和Client Credentials Grant的方式来获取Access Token,为什么OIDC没有扩展这些方式呢?

    Resource Owner Password Credentials Grant是需要用途提供账号密码给RP的,账号密码给到RP了,还要什么自行车(ID Token)。。。

    Client Credentials Grant这种方式根本就不需要用户参与,更谈不上用户身份认证了。这也能反映授权和认证的差异,以及只使用OAuth2来做身份认证的事情是远远不够的,也是不合适的。

    3.4.1 基于Authorization Code的认证请求

    这种方式使用OAuth2的Authorization Code的方式来完成用户身份认证,所有的Token都是通过Token EndPoint(OAuth2中定义:https://tools.ietf.org/html/rfc6749#section-3.2)来发放的。构建一个OIDC的Authentication Request需要提供如下的参数:

    1. scope:必须。OIDC的请求必须包含值为“openid”的scope的参数。
    2. response_type:必选。同OAuth2。
    3. client_id:必选。同OAuth2。
    4. redirect_uri:必选。同OAuth2。
    5. state:推荐。同OAuth2。防止CSRF, XSRF。

    以上这5个参数是和OAuth2相同的。除此之外,还定义了如下的参数:

    1. response_mode:可选。OIDC新定义的参数(OAuth 2.0 Form Post Response Mode),用来指定Authorization Endpoint以何种方式返回数据。
    2. nonce:可选。ID Token中的出现的nonce就是来源于此。
    3. display : 可选。指示授权服务器呈现怎样的界面给EU。有效值有(page,popup,touch,wap),其中默认是page。page=普通的页面,popup=弹出框,touch=支持触控的页面,wap=移动端页面。
    4. prompt:可选。这个参数允许传递多个值,使用空格分隔。用来指示授权服务器是否引导EU重新认证和同意授权(consent,就是EU完成身份认证后的确认同意授权的页面)。有效值有(none,login,consent,select_account)。none=不实现现任何认证和确认同意授权的页面,如果没有认证授权过,则返回错误login_required或interaction_required。login=重新引导EU进行身份认证,即使已经登录。consent=重新引导EU确认同意授权。select_account=假如EU在授权服务器有多个账号的话,允许EU选择一个账号进行认证。
    5. max_age:可选。代表EU认证信息的有效时间,对应ID Token中auth_time的claim。比如设定是20分钟,则超过了时间,则需要引导EU重新认证。
    6. ui_locales:可选。用户界面的本地化语言设置项。
    7. id_token_hint:可选。之前发放的ID Token,如果ID Token经过验证且是有效的,则需要返回一个正常的响应;如果有误,则返回对应的错误提示。
    8. login_hint:可选。向授权服务器提示登录标识符,EU可能会使用它登录(如果需要的话)。比如指定使用用户使用blackheart账号登录,当然EU也可以使用其他账号登录,这只是类似html中input元素的placeholder。
    9. acr_values:可选。Authentication Context Class Reference values,对应ID Token中的acr的Claim。此参数允许多个值出现,使用空格分割。

    以上是基于Authorization Code方式的OIDC的认证请求所需的参数。在OIDC的其他认证流程中也会有其他的参数或不同的参数值(稍有差异)。一个简单的示例如下:

    GET /authorize?
        response_type=code
        &scope=openid%20profile%20email
        &client_id=s6BhdRkqt3
        &state=af0ifjsldkj
        &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
      Host: server.example.com

    也可以是一个基于302的重定向方式。

    3.4.2 基于Authorization Code的认证请求的响应

    在授权服务器接收到认证请求之后,需要对请求参数做严格的验证,具体的规则参见http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation,验证通过后引导EU进行身份认证并且同意授权。在这一切都完成后,会重定向到RP指定的回调地址,并且把code和state参数传递过去。比如:

      HTTP/1.1 302 Found
      Location: https://client.example.org/cb?
        code=SplxlOBeZQQYbYS6WxSbIA
        &state=af0ifjsldkj

    3.4.3 获取ID Token

    RP使用上一步获得的code来请求Token EndPoint,这一步同OAuth2,就不再展开细说了。然后Token EndPoint会返回响应的Token,其中除了OAuth2规定的部分数据外,还会附加一个id_token的字段。id_token字段就是上面提到的ID Token。例如:

      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store
      Pragma: no-cache
    
      {
       "access_token": "SlAV32hkKG",
       "token_type": "Bearer",
       "refresh_token": "8xLOxBtZp8",
       "expires_in": 3600,
       "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
         yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
         NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
         fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
         AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
         Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
         NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
         QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
         K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
         XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
      }

    其中看起来一堆乱码的部分就是JWT格式的ID Token。在RP拿到这些信息之后,需要对id_token以及access_token进行验证(具体的规则参见http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidationhttp://openid.net/specs/openid-connect-core-1_0.html#ImplicitTokenValidation)。至此,可以说用户身份认证就可以完成了,后续可以根据UserInfo EndPoint获取更完整的信息。

    3.4.4 Implicit Flow和Hybrid Flow

    Implicit Flow的工作方式是在OAuth2 Implicit Flow上附加提供id_token,当然,认证请求的参数和基于Authorization Code的流程稍有不同,具体的差异参见http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest,这里就不做详细介绍了。

    Hybrid Flow则=Authorization Code Flow+Implicit Flow,也不再详细介绍了。

    3.5 UserInfo Endpoint

    UserIndo EndPoint是一个受OAuth2保护的资源。在RP得到Access Token后可以请求此资源,然后获得一组EU相关的Claims,这些信息可以说是ID Token的扩展,比如如果你觉得ID Token中只需包含EU的唯一标识sub即可(避免ID Token过于庞大),然后通过此接口获取完整的EU的信息。此资源必须部署在TLS之上,例如:

      GET /userinfo HTTP/1.1
      Host: server.example.com
      Authorization: Bearer SlAV32hkKG

    成功之后响应如下:

      HTTP/1.1 200 OK
      Content-Type: application/json
    
      {
       "sub": "248289761001",
       "name": "Jane Doe",
       "given_name": "Jane",
       "family_name": "Doe",
       "preferred_username": "j.doe",
       "email": "janedoe@example.com",
       "picture": "http://example.com/janedoe/me.jpg"
      }

    其中sub代表EU的唯一标识,这个claim是必须的,其他的都是可选的。

    4 总结

    继OAuth2之后,感觉OIDC也要大放异彩了。其本身是一个完全开放的标准,而且兼容众多的已有的IDP(身份提供商),比如基于SAML的、基于WS-Federation的等等已有的身份认证系统,都可以作为OIDC的OP存在。总结一下OIDC有那些特性和好处吧:

    1. OIDC使得身份认证可以作为一个服务存在。
    2. OIDC可以很方便的实现SSO(跨顶级域)。
    3. OIDC兼容OAuth2,可以使用Access Token控制受保护的API资源。
    4. OIDC可以兼容众多的IDP作为OIDC的OP来使用。
    5. OIDC的一些敏感接口均强制要求TLS,除此之外,得益于JWT,JWS,JWE家族的安全机制,使得一些敏感信息可以进行数字签名、加密和验证,进一步确保整个认证过程中的安全保障。

    以上内容均是个人的一些理解,如果错误之处,欢迎指正!

    5 Example

    笔者基于IdentityServer3和IdentitySever4(两者都是基于OIDC的一个.NET版本的开源实现)写的一个集成SSO,API访问授权控制,QQ联合登陆(作为OP)的demo:https://github.com/linianhui/oidc.example 。

    6 参考

    官方资料:

    http://openid.net/connect/

    http://openid.net/connect/faq/

    http://openid.net/developers/certified/

    JWT : https://tools.ietf.org/html/rfc7519

    JWS:https://tools.ietf.org/html/rfc7515

    JWE:https://tools.ietf.org/html/rfc7516

    .NET的开源实现:https://github.com/IdentityServer

    视频:Identity, Authentication + OAuth = OpenID Connect

    案例:

    https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-openid-connect-code

    https://developers.google.com/identity/protocols/OpenIDConnect

     

    原文地址:https://www.cnblogs.com/linianhui/p/openid-connect-core.html

    展开全文
  • kubernetes安全控制认证与授权(一)

    万次阅读 2017-07-23 08:49:50
    kubernetes 对于访问 API 来说提供了两个步骤的安全措施:认证和授权。认证解决用户是谁的问题,授权解决用户能做什么的问题。通过合理的权限管理,能够保证系统的安全可靠。通俗的讲,认证就是验证用户名密码,授权...

    kubernetes 对于访问 API 来说提供了两个步骤的安全措施:认证和授权。认证解决用户是谁的问题,授权解决用户能做什么的问题。通过合理的权限管理,能够保证系统的安全可靠。

    通俗的讲,认证就是验证用户名密码,授权就是检查该用户是否拥有权限访问请求的资源。

    Kubernetes集群的所有操作基本上都是通过kube-apiserver这个组件进行的,它提供HTTP RESTful形式的API供集群内外客户端调用。需要注意的是:认证授权过程只存在HTTPS形式的API中。也就是说,如果客户端使用HTTP连接到kube-apiserver,那么是不会进行认证授权的。所以说,可以这么设置,在集群内部组件间通信使用HTTP,集群外部就使用HTTPS,这样既增加了安全性,也不至于太复杂。

    下图是 API 访问要经过的三个步骤,前面两个是认证和授权,第三个是 Admission Control,它也能在一定程度上提高安全性,不过更多是资源管理方面的作用。

    authenticating.png-33.8kB

    下面将介绍1.6版本中已经支持的一些认证方式。

    客户端证书

    客户端证书认证叫作TLS双向认证,也就是服务器客户端互相验证证书的正确性,在都正确的情况下协调通信加密方案。

    为了使用这个方案,api-server需要用-client-ca-file=选项来开启。CA_CERTIFICATE_FILE肯定包括一个或者多个认证中心,可以被用来验证呈现给api-server的客户端证书。客户端证书的/CN将作为用户名。

    静态Token文件

    用token唯一标识请求者,只要apiserver存在该token,则认为认证通过,但是如果需要新增Token,则需要重启kube-apiserver组件,实际效果不是很好。

    当在命令行指定- -token-auth-file=SOMEFILE选项时,API服务器从文件中读取 bearer tokens。目前,tokens持续无限期。

    令牌文件是一个至少包含3列的csv文件: token, user name, user uid,后跟可选的组名。注意,如果您有多个组,则列必须是双引号,例如:

    token,user,uid,"group1,group2,group3"

    当通过客户端使用 bearer token 认证时,API服务器需要一个值为Bearer THETOKEN的授权头。bearer token必须是,可以放在HTTP请求头中且值不需要转码和引用的一个字符串。例如:如果bearer token是31ada4fd-adec-460c-809a-9e56ceb75269,它将会在HTTP头中按下面的方式呈现:

    Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

    引导Token

    在v1.6版本中,这个特性还是alpha特性。为了能够在新的集群中使用bootstrapping认证。Kubernetes包括一种动态管理的Bearer(持票人) token,这种token以Secrets的方式存储在kube-system命名空间中,在这个命名空间token可以被动态的管理和创建。Controller Manager有一个管理中心,如果token过期了就会删除。

    创建的token证书满足[a-z0-9]{6}.[a-z0-9]{16}格式,Token的第一部分是一个Token ID,第二部分是token的秘钥。你需要在http协议头中加上类似的信息:

    Authorization: Bearer 781292.db7bc3a58fc5f07e

    如果要使用Bootstrap,需要在API Sever中开启--experimental-bootstrap-token-auth。同时必须在Controller Manager中开启管理中心的设置--controllers=*,tokencleaner

    在使用kubeadm部署Kubernetes时,kubeadm会自动创建默认token,可通过kubeadm token list命令查询。

    静态密码文件

    静态密码的方式是提前在某个文件中保存了用户名和密码的信息,然后在 apiserver 启动的时候通过参数 –basic-auth-file=SOMEFILE 指定文件的路径。apiserver 一旦启动,加载的用户名和密码信息就不会发生改变,任何对源文件的修改必须重启 apiserver 才能生效。

    静态密码文件是 CSV 格式的文件,每行对应一个用户的信息,前面三列密码、用户名、用户 ID 是必须的,第四列是可选的组名(如果有多个组,必须用双引号):

    password,user,uid,"group1,group2,group3"

    客户端在发送请求的时候需要在请求头部添加上 Authorization 字段,对应的值是 Basic BASE64ENCODED(USER:PASSWORD) 。apiserver 解析出客户端提供的用户名和密码,如果和文件中的某一行匹配,就认为认证成功。

    注意:
    这种方式很不灵活,也不安全,可以说名存实亡,不推荐使用。

    Service Account Tokens 认证

    有些情况下,我们希望在 pod 内部访问 apiserver,获取集群的信息,甚至对集群进行改动。针对这种情况,kubernetes 提供了一种特殊的认证方式:Service Account。 Service Account 是面向 namespace 的,每个 namespace 创建的时候,kubernetes 会自动在这个 namespace 下面创建一个默认的 Service Account;并且这个 Service Account 只能访问该 namespace 的资源。Service Account 和 pod、service、deployment 一样是 kubernetes 集群中的一种资源,用户也可以创建自己的 serviceaccount。

    ServiceAccount 主要包含了三个内容:namespace、Token 和 CA。namespace 指定了 pod 所在的 namespace,CA 用于验证 apiserver 的证书,token 用作身份验证。它们都通过 mount 的方式保存在 pod 的文件系统中,其中 token 保存的路径是 /var/run/secrets/kubernetes.io/serviceaccount/token ,是 apiserver 通过私钥签发 token 的 base64 编码后的结果; CA 保存的路径是 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt ,namespace 保存的路径是 /var/run/secrets/kubernetes.io/serviceaccount/namespace ,也是用 base64 编码。

    如果 token 能够通过认证,那么请求的用户名将被设置为 system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT) ,而请求的组名有两个: system:serviceaccounts 和 system:serviceaccounts:(NAMESPACE)。

    关于 Service Account 的配置可以参考官方的 Manager Service Accounts 文档。

    OpenID Connect Tokens 认证

    OpenID Connect 是一些由OAuth2提供商支持的OAuth2,特别是Azure Active Directory,Salesforce和Google。OAuth2的协议的主要扩展是增加一个额外字段,返回了一个叫ID token的access token。这个token是被服务器签名的JSON Web Token (JWT) ,具有众所周知的字段,比如用户的email。

    为了识别用户,验证使用来自OAuth2 token响应的id_token (而不是 access_token)作为bearer token。token如何包含在请求中可以参考下图:
    oidc.png-55.3kB

    使用OpenID认证,API Server需要配置
    - --oidc-issuer-url,如https://accounts.google.com
    - --oidc-client-id,如kubernetes
    - --oidc-username-claim,如sub
    - --oidc-groups-claim,如groups
    - --oidc-ca-file,如/etc/kubernetes/ssl/kc-ca.pem

    Webhook Token 认证

    Webhook Token 认证方式可以让用户使用自己的认证方式,用户只需要按照约定的请求格式和应答格式提供 HTTPS 服务,当用户把 Bearer Token 放到请求的头部,kubernetes 会把 token 发送给事先配置的地址进行认证,如果认证结果成功,则认为请求用户合法。 这种方式下有两个参数可以配置:

    –authentication-token-webhook-config-file :kubeconfig 文件说明如果访问认证服务器

    –authentication-token-webhook-cache-ttl :认证结果要缓存多久,默认是两分钟
    这种方式下,自定义认证的请求和应答都有一定的格式,具体的规范请参考 官方文档的说明 。

    认证代理

    API Server需要配置

    --requestheader-username-headers=X-Remote-User
    --requestheader-group-headers=X-Remote-Group
    --requestheader-extra-headers-prefix=X-Remote-Extra-
    # 为了防止头部欺骗,证书是必选项
    --requestheader-client-ca-file
    # 设置允许的CN列表。可选。
    --requestheader-allowed-names

    Keystone Password 认证

    Keystone 是 openstack 提供的认证和授权组件,这个方法对于已经使用 openstack 来搭建 Iaas 平台的公司比较适用,直接使用 keystone 可以保证 Iaas 和 Caas 平台保持一致的用户体系。

    需要API Server在启动时指定--experimental-keystone-url=<AuthURL>,而https时还需要设置--experimental-keystone-ca-file=SOMEFILE

    匿名请求

    如果请求没有通过以上任何方式的认证,正常情况下应该是直接返回 401 错误。但是 kubernetes 还提供另外一种选择,给没有通过认证的请求一个特殊的用户名 system:anonymous 和组名 system:unauthenticated 。

    这样的话,可以跟下面要讲的授权结合起来,为匿名请求设置一些特殊的权限,比如只能读取当前 namespace 的 pod 信息,方便用户访问。

    如果使用AlwaysAllow以外的认证模式,则匿名请求默认开启,但可用--anonymous-auth=false禁止匿名请求。

    展开全文
  • options.Scope.Add("yingyu88api"); //options.Scope.Add("offline_access"); //options.ClaimActions.MapJsonKey("website", "website"); }); } public void Configure...
  • 文章目录认证授权服务中客户端配置的修改MVC网站客户端的修改使用`访问令牌`访问API服务 本篇基于前文介绍的API访问的控制和用户身份的认证,本篇将在ASP.NET Core应用中把这两者结合起来。 OpenID Connect和OAuth ...
  • IdentityServer4-前后端分离之Vue

    千次阅读 2019-03-25 17:44:24
    前言之前文章讲到如何使用Node.js+Express构建JavaScript客户端,实现前后端分离。本节将介绍如何使用Vue实现前后端分离,文中介绍Vue的知识比较基...
  • 采用Client Credentials方式,即应用公钥、密钥方式获取Access Token,适用于任何类型应用,但通过它所获取的Access Token只能用于访问与用户无关的Open API,并且需要开发者提前向开放平台申请,成功对接后方能使用...
  • 作者|Alexey Ledenev翻译 | 天道酬勤,责编 |Carol出品 | CSDN云计算(ID:CSDNcloud)随着企业与各种云提供商合作,多云场景已经变得十分常见。在谷...
  • 2、Kubernetes apiserver认证

    千次阅读 2018-06-06 15:03:07
    https://blog.csdn.net/yan234280533/article/details/75808048kubernetes 对于访问 API 来说提供了两个步骤的安全措施:认证和授权。认证解决用户是谁的问题,授权解决用户能做什么的问题。通过合理的权限管理,...
  • if (!(Test-Path -Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE -Force }
  •   主要用于第三方应用登录,例如使用QQ或微信登录其他的应用或网站等。目的在于限制用户身份,有效的身份才能浏览相关的内容。这就是认证和授权!! 1 OpenID   它是一种认证标准,用户要使用OpenID就必须在...
  • 如果想完全理解本文所涉及到的话题,你需要了解的背景知识有:什么是OpenId Connect (OIDC)OIDC 对oAuth进行了哪些扩展?Identity Server4提供的OIDC认证服务(服务端)ASP.NET Core的权限体系中的OIDC认证框架...
  • 预备知识: 学习Identity Server 4的预备知识 第一部分: 使用Identity Server 4建立Authorization Server (1) ...第二部分: 使用Identity ... Server 4建立Authorization Server (2) ... Server 4建立Authorization...
  • Pac4j文档翻译(3.0)

    千次阅读 2018-03-29 16:13:57
    pac4j是一个简单而强大的安全引擎,用于Java对用户进行身份验证、获取其配置文件和管理授权,以确保web应用程序安全。它提供了一套完整的概念和组件。它基于Java 8,并在Apache 2许可下使用...
  • Kubernetes实现SSO登录(一)

    千次阅读 2018-05-23 15:20:32
    【编者的话】你是否也在为登录各种网站,提交身份信息而烦恼?是否有一种更省时、省事的打开方式?好吧,让我们来看看原文的作者Joel Speed是如何利用SSO,开启Kubernetes的正确方式。原文是连载的方式,以下是第一...
  • ASP.NET Core 认证与授权[4]:JwtBearer认证

    千次阅读 2017-11-13 13:05:29
    质询与应答的工作流程如下:服务器端向客户端返回401(Unauthorized,未授权)状态码,并在WWW-Authenticate头中添加如何进行验证的信息,其中至少包含有一种质询方式。然后客户端可以在请求中添加Authorization头进
  • 实现OpenStack的单点登录

    千次阅读 2017-08-07 14:36:36
    本文要解决的问题是,如何在基于CentOS 7.3的OpenStack上配置单点登录(Single Sign On): 所使用的第三方认证是Google帐号,而认证方法是OpenID Connect.
  • RESTful 详解

    千次阅读 2016-09-10 16:13:54
    1. 什么是REST  REST全称是Representational State Transfer,中文意思是表述(编者注:通常译为表征)性状态转移。... 他在论文中提到:“我这篇文章的写作目的,就是想在符合架构原理的前提下,理解和评估以网络为...
  • CAS单点登录-第三方登录[QQ、微信、CSDN、GitHub](十四) 注: 目前博文使用cas版本为5.1.5,由于5.2.x与5.1.x构建模式有差异,所以部分配置会有些差异。 本章内容 简答介绍OAuth2 ...很多朋友问我,怎么集成QQ、...
1 2 3 4 5 ... 20
收藏数 550
精华内容 220
关键字:

webapi 获取oidc的信息