参考
- 简单了解概念: https://www.bilibili.com/video/BV1XG411w7DN/
- 简单了解操作: https://www.bilibili.com/video/BV1334y11739/ openid-connect
- 👍流程图解: https://www.youtube.com/watch?v=t18YB3xDfXI (图:https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc)
流程案例: https://www.youtube.com/watch?v=996OiexHze0- 流程案例(with docker Keycloak): https://www.bilibili.com/video/BV1334y11739/
backup https://archive.org/details/keycloakopenid-connectflow-pundefined-output-264- 代码: https://www.bilibili.com/video/BV1hP4y1C7w8/
- How to Hack OAuth - https://www.youtube.com/watch?v=aU9RsE4fcRM
- news - https://www.youtube.com/watch?v=g_aVPdwBTfw&list=PLshTZo9V1-aEUg2S84KlisJBAyMEoEZ45
OAuth 2.0
Authentication authN —— 认证 Who are you
Authorization authZ —— 授权 What can you do
OAuth 2.0 is a security standard where you give one application permission to access your data in another application instead of giving them your username and password. You can essentially give one app a key that gives them specific permission to access your data do things on your behalf in another application. —— authorization、delegate authorization
假设一个网站A想要你的联系人目录,你可以把gmail的联系人目录(contacts)给它。这过程就需要gmail授权(authorization)
- 没登录gmail,登录gmail
- 登录gmail后,gmail会询问你是否授权
- 你在gmail点击授权后,生成一个凭证(token)
- 网站A就可以携带这凭证到gmail中获取你的联系人目录
- 这一般是网站A后台进行,但协议具体没规定,只规定了gmail可以将你的联系人目录响应给携带token的请求。
OAuth flow: 就是上述(你看得到、看不到)的流程
terminology
-
resource owner
- you (the data owner) -
client
- 请求授权的应用(上述网站A) -
authorization server
- the application that knows theresource owner
where the resource owner already has a account(上述gmail,认证那部分) -
resource server
- the application programming interface (API) (上述gmail,提供数据那部分)
(⚠resource server
、authorization server
可以是不同的!) -
redirect url
- the URL that theauthorization server
will redirect theresource owner
back to after grant permission to theclient
-
response type
- the type of information theclient
expects to receive.- code (常见) - 直接响应授权代码(authorization code)
-
scope
- 授权的范围,由资源服务商(resource server
)自己规定- 如上述例子中,可以有如下范围
- read contacts
- create contact
- delete contact
- read profile
- …
- 如上述例子中,可以有如下范围
-
consent
- theauthorization server
takes thescopes
theclient
is requesting and verifies with theresource owner
whether or not they want to give theclient
permission.
-
client id
- it is generated by theauthorization server
and is used to identify theclient
with theauthorization server
-
client secret
- a secret password that is generated by theauthorization server
and only theclient
andauthorization server
know. this allows them to secretly share information privately behind the scenes -
authorization code
- a short-lived temporary code theauthorization server
send back to theclient
. theclient
then privately send theauthorization code
back to theauthorization server
along with the client secret in exchange for aaccess token
-
access token
- the key theclient
will use form that point forward to communicate with theresource server
. this is like a key or a key card that give theclient
permission to request data or perform actions with theresource server
on your behalf
example: what’s going on throughout the OAuth flow
- you (
resource owner
) want to allow 网站A (client
) to access your contacts - the
client
redirect your browser to theauthorization server
and include with the request theclient id
,redirect uri
,response type
and one or morescope
s it needs - the
authorization server
verifies whoyou
are and if necessary to prompt a login - the
authorization server
then presentsyou
with a form based on thescope
s requested by theclient
andyou
have the opportunity to grant or deny permission - the
authorization server
redirects back to theclient
using theredirect uri
along with a temporaryauthorization code
- the
client
then contacts theauthorization server
directly, which means that theclient
don’t use theyou
r browser and securely sends itsclient id
andclient secret
andauthorization code
- the
authorization server
verifies the data and responds with anaccess token
- the
access token
is a value theclient
dosen’t understand as far as theclient
is concerned theaccess token
is just a string of gibberish. however theclient
can use theaccess token
to send request to theresource server
- the
resource server
verifies the access token and if valid responds with the data requested by theclient
OAuth Server (well-known authorization server)
- https://oauth2.thephpleague.com
- Google OAuth playground
- https://openidconnect.net
- https://developer.okta.com
OIDC - OpenID connect
OAuth 2.0 只设计了授权(authorization)环节。在这个授权环节中,数据请求方(客户端,client)最终只拿到一个可以去取数据的access token。在取得数据前,client都无法知道你(you, resource owner)是谁
OIDC is a thin layer that site on top of OAuth 2.0 that adds functionality around login and profile information about the person who is logging in
instead of a key, OIDC is like giving the client application a badge (标记) the badge not only gives the clients specific permission it also provides some basic information about who you are
where OAuth enables authorization from one app to another, OIDC enable a client to establish a login session often referred to as authentication as well as to gain information about the person login in the resource owner which is often called identity
when an authorization server supports OIDC is sometimes called an identity provider since it provides information about the resource owner back to the client
OpenID connect enables scenarios where one login can be use across multiple applications also known as single sign-on SSO. for example an application could support SSO with social networking services such as Facebook or Twitter so that users can choose to leverage a login they already have and are comfortable using
example
- you点击
client
中的授权链接 - 💡
client
将的的浏览器重定向到authorization server
地址,其中scope
为openid
(而不再是什么read contacts、delete contact、…) -
authorization server
校验you -
authorization server
询问you -
authorization server
给client
响应authorization code
-
client
携带authorization code
和其他信息与authorization server
联系 - 💡
authorization server
校验信息无误后返回access token
和id token
这里的id token
是携带你信息的,这些信息可以被client
识别、存储。它的格式一般是json,称为JSON web token,JWT。这里包含的信息成为之claims
3 - 6 stop are same
通过IODC,client拿到你在resource server中的登录信息
Hack OAuth
RFC 6749 Section 10
RFC 8252 Section 8
RFC 6819
draft-ietf-oauth-security-topics
AppAuth.io
文章来源:https://www.toymoban.com/news/detail-453703.html
todo https://blog.csdn.net/LawssssCat/article/details/105065992
todo https://lawsssscat.blog.csdn.net/article/details/106989017
todo https://lawsssscat.blog.csdn.net/article/details/104811038
todo 整理关键词:oauth、auth、认证、…文章来源地址https://www.toymoban.com/news/detail-453703.html
到了这里,关于SSO、CAS、OAuth、OIDC的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!