参考

• 简单了解概念： 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
• 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 the resource 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 the authorization server will redirect the resource owner back to after grant permission to the client
• response type - the type of information the client expects to receive.
  • code （常见） - 直接响应授权代码（authorization code）
• scope - 授权的范围，由资源服务商（resource server）自己规定
  • 如上述例子中，可以有如下范围
    • read contacts
    • create contact
    • delete contact
    • read profile
    • …
• consent - the authorization server takes the scopes the client is requesting and verifies with the resource owner whether or not they want to give the client permission.
  
• client id - it is generated by the authorization server and is used to identify the client with the authorization server
• client secret - a secret password that is generated by the authorization server and only the client and authorization server know. this allows them to secretly share information privately behind the scenes
• authorization code - a short-lived temporary code the authorization server send back to the client. the client then privately send the authorization code back to the authorization server along with the client secret in exchange for a access token
• access token - the key the client will use form that point forward to communicate with the resource server. this is like a key or a key card that give the client permission to request data or perform actions with the resource server on your behalf
  

example: what’s going on throughout the OAuth flow

1. you (resource owner) want to allow 网站A (client) to access your contacts
2. the client redirect your browser to the authorization server and include with the request the client id, redirect uri, response type and one or more scopes it needs
3. the authorization server verifies who you are and if necessary to prompt a login
4. the authorization server then presents you with a form based on the scopes requested by the client and you have the opportunity to grant or deny permission
5. the authorization server redirects back to the client using the redirect uri along with a temporary authorization code
6. the client then contacts the authorization server directly, which means that the client don’t use the your browser and securely sends its client id and client secret and authorization code
7. the authorization server verifies the data and responds with an access token
8. the access token is a value the client dosen’t understand as far as the client is concerned the access token is just a string of gibberish. however the client can use the access token to send request to the resource server
9. the resource server verifies the access token and if valid responds with the data requested by the client

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

1. you点击client中的授权链接
2. 💡 client将的的浏览器重定向到authorization server地址，其中scope为openid （而不再是什么read contacts、delete contact、…）
3. authorization server校验you
4. authorization server询问you
5. authorization server给client响应authorization code
6. client携带authorization code和其他信息与authorization server联系
7. 💡 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

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、认证、…