前言
如果大家有接触过ADFS或者认证协议,肯定会对五花八门的名词看服务器托管的眼花缭乱,比如WS-FED、SAML、SAML Token、OAuth、OpenID Connect、Kerbros以及NTLM等, 但实际上我们可以高屋建瓴的学习它们。
拆分
作为程序员或者工程师,我们都擅长将问题拆分和类比,在认证协议上我们同样可以如此分为三方面,登录协议,验证过程以及令牌类型。举个例子,当我们坐飞机时,首先去柜台办理登记手续,出示自己的身份证,然后工作人员会返回给你机票,然后可以拿着身份证去登机口登机。那么这三个方面都是什么?
-
登录协议,整个登机的过程就是一个登录协议,规定了整套登机的服务器托管流程。而WS-FED、SAML、OAuth、OpenID Connect属于登录协议。
-
验证过程,在柜台出示身份证,然后交换机票的这个过程被称为验证过程。普通的password认证,以及Kerbros和NTLM属于验证过程。
-
令牌,在整个流程中,机票就是属于令牌。 而在认证协议中令牌也有很多种,最常见的是OAuth中的JWT,Json Web Token。需要注意SAML Token此时属于令牌而不是协议。
WS-FED
WS-FED是ADFS Server的登录协议,从三方面来解释这个协议
-
登录协议,属于WS-FED
-
验证过程,支持多种验证过程,包括Forms-based即password, Kerbros 和NTLM。
-
令牌,注意用WS-Fed时,令牌一般是SAML 1.1 Token
那么WS-FED的URL一般是这样的, https://sts.example.com/adfs/ls/? wa=wsignin1.0 & wtrealm=… & wctx=…
参数分别代表的内容如下:
-
wa=wsignin1.0,通知ADFS server登录,这是一个登录操作
-
Wtrealm, 通知ADFS server, 我要获取什么, 比如跟ADFS Server配置的relying party相对应
-
wctx, 认证之后返回去的session data
拓展知识:
Kerbros和NTLM都是windows认证,其中NTLM时属于比较旧的协议,相对于Kerbros是不安全的协议,所以一般作为Kerbros的Fallback
SAML
SAML也是ADFS Server的登录协议,还是从三方面来解释这个协议
-
登录协议,属于SAML
-
验证过程,支持多种验证过程,包括Forms-based即password, Kerbros 和NTLM。
-
令牌,注意用WS-Fed时,令牌一般是SAML 2.0 Token
那么SAML的URL一般是这样的, https://sts.example.com/adfs/ls/? SAMLRequest=… & SigAlg=… & RelayState=… & Signature=…
参数分别代表的内容如下:
-
SAMLRequest, Base64格式,请求内容
-
SigAlg, 签名算法
-
Signature, 对request的签名
-
RelayState, 认证之后返回去的session data
OAuth和OpenID Connect
OAuth 是一种开放标准的授权协议,允许用户让第三方应用访问他们存储在另外服务提供商上的信息而无需将用户名和密码提供给第三方应用。OAuth 作为授权框架,允许第三方应用限定的访问权限,这样用户就不需要与第三方应用共享登录凭据。
举例来说,一个网站(称为客户端)可能允许用户通过Github账户登录,用户可以点击一键登录的按钮,然后被重定向到Github的登录页。在那里,用户输入自己的登录凭据,然后Github会提示用户是否授权那个网站访问其某些信息。一旦用户同意,Github会将用户重定向回原来的网站,同时提供一个授权码。最后,该网站可以使用这个授权码向 Github 请求访问令牌,并使用这个令牌来获取用户信息。
OpenID Connect 是建立在 OAuth 2.0 协议之上的一个身份层,提供了一种身份验证的方式。它允许客户端应用程序依靠授权服务器来验证最终用户的身份,并获取基本的个人资料信息。OpenID Connect 是一个简单的身份验证协议,并且可以和OAuth 2.0无缝集成。
与OAuth 2.0 主要是为了授权访问资源不同,OpenID Connect 提供了更丰富的身份认证信息,通常包含用户的ID令牌和用户信息(比如用户的姓名、邮箱地址等)。
还是从三方面来解释这个协议
-
登录协议, OAuth, OIDC
-
验证过程,支持多种验证过程,包括Forms-based即password, MFA等
-
令牌,JWT即Json Web Token
OAuth 2.0支持很多flow,比如Code flow, Client Credentials Grant flow, Device Code flow等, Code flow的URL一般是
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&state=12345
而OpenID Connect的URL一般是
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=form_post
&scope=openid
&state=12345
&nonce=678910
欢迎扫码关注我的公众号
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net
相关推荐: 基于 Webpack 插件体系的 Mock 服务
背景 在软件研发流程中,对于前后端分离的架构体系而言,为了能够更快速、高效的实现功能的开发,研发团队通常来说会在产品原型阶段对前后端联调的数据接口进行结构设计及约定,进而可以分别同步进行对应功能的实现,提升研发速率。除了常见的研发流程提效之外,对于一些特殊的无…