我不明白这1
部分。
例如,我有一个网站asdf.com
并使用google
OP,所以我在我的网站上有一个带有指向 google 网站login with google
的链接(类似于 )的按钮。https://account.google.com/XXX?return_url=asdf.com
所以用户会点击这个按钮登录,所以我认为1
步骤应该是enduser -> OP
?为什么RP -> OP
?
我不明白这1
部分。
例如,我有一个网站asdf.com
并使用google
OP,所以我在我的网站上有一个带有指向 google 网站login with google
的链接(类似于 )的按钮。https://account.google.com/XXX?return_url=asdf.com
所以用户会点击这个按钮登录,所以我认为1
步骤应该是enduser -> OP
?为什么RP -> OP
?
让我们分块来看这个还不如把它们都拿走。这称为 Oauth2 舞蹈或三足 Oauth2 流程。舞蹈中需要三个步骤才能获得授权。有两个主要的玩家Client Application
和他们Authentication server
一起resource owner
玩侧滚。
步骤1:
[客户端应用程序] 联系身份验证服务器。说我有一个用户想同意登录我的应用程序。
[认证服务器]确定没问题用户必须先登录,然后我将显示他们一个同意屏幕
https://accounts.google.com/o/oauth2/auth?client_id= {clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope= https://www.googleapis.com/ auth/analytics.readonly&response_type=code
[资源所有者(用户)] 同意。
第2步:
[认证服务器]响应客户端。嘿,您的用户说您可以访问这里是授权码。
[客户端应用程序]感谢这里的授权代码,我的客户端 ID 和密码(客户端 ID 和密码基本上是客户端向授权服务器识别它的登录名和密码)这应该向您验证我就是我。
https://accounts.google.com/o/oauth2/token code=4/X9lG6uWd8-MMJPElWggHZRzyFKtp.QubAT_P-GEwePvB8fYmgkJzntDnaiAI&client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&redirect_uri=urn:ietf:wg:oauth: 2.0:oob&grant_type=authorization_code
步骤 3。
[身份验证服务器] 真棒,看起来你这里有一个访问令牌,可能还有一个刷新令牌。
注释:
Open id connect 基本上建立在 Oauth2 之上,主要区别在于您发送的范围是 openid 。
如果你想要有趣的Oauth2 游乐场,你可以在这里测试它
是的,我会说你是对的:对 OP 的第一个请求来自最终用户。
RP 通常将请求构建到 OPsauthorise
端点,但随后它将最终用户的浏览器重定向到该端点(例如通过 HTTP 302 响应),或者将构建的 URL 作为操作放置在返回的 html 页面上的链接/按钮上从 RP 到最终用户。
这似乎在图表上丢失了。