oauth2+oidc协议(重点摘录)
2024-01-19 11:20:09 1 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
OAuth 2.0和OpenID Connect（OIDC）是两种广泛的认证和授权协议，用于保障Web和移动应用程序的安全。OAuth 2.0是一种授权协议，允许用户授权第三方应用程序访问他们的资源，而无需共享他们的凭证。OIDC则是一种基于OAuth 2.0的身份验证协议，允许用户通过身份提供商（IdP）进行身份验证，并获取他们的身份验证信息。这种组合提供了一种灵活且安全的方式，让用户能够登录到各种应用程序，同时保护他们的隐私和数据安全。
作者其他创作
大纲/内容
core
minimal
discovery
dynamic client registration
外框
dynamic
session management
form post response mode
complete
协议簇总览
FAPIFinancial-grade API
HEARTHealth Relationship Trust
EAPEnhanced Authentication Profile
SSEShared Signals and Events
eKYC-IDAeKYC and Identity Assurance
工作组
注册、登录、注销
基础模式，适用于web
1.0
代理模式，适用于非web
2.0
实现1：CAS
实现2：OIDC
SSO
认证(authN)
用户
资源存储
第三方
委托授权(authZ)delegated authorization
APIKEY
HMAC算法
alg
typ
header
https://etas.xiamenair.com.cn
iss
工号
sub
必须包含 client_id
aud
过期时间可以留有余量，以防系统时钟偏差
exp
issued at签发时间
iat
nbf
jti
name
admin
nonce
auth_time
acr
....
其他可自定义
payload
官方7字段
对称加密HMAC【哈希消息验证码】：HS256/HS384/HS512
非对称加密RSASSA【RSA签名算法】（RS256/RS384/RS512）
ECDSA【椭圆曲线数据签名算法】（ES256/ES384/ES512）
到目前为止，jwt的签名算法有三种。
signature
3大块
url
post body
可以放在
签名，完整性
JWSJSON Web Signature
加密，保密性
JWEJSON Web Encryption
两种实现方式
定义
例子
EC 或 RS加密算法族
表明算法目的，sig (signature) 或 enc (encryption)
use
kid
member-common
n：modulus
mod
e：exponent
member-RSA
JWK/JWKS
转成公钥pem
JWA(JSON Web Algorithms)
JOSE(JSON Object Signing and Encryption)
其他概念
JWT
TGT（Ticket Granting Ticket）
key:CASTGC
一个TGT 的 ID标识
value
is cookie
TGC（Ticket Granting Cookie）
CAS为用户签发的访问某一service的票据，ST是TGT签发的。
ST（Service Ticket）
CAS单点登录
对客OAUTH
其他
跨站请求伪造
CSRFcross-site request forgery
跨站脚本攻击
XSScross-site script
跨域资源共享
CORScross origin resourse-sharing
cross 3概念
terminology
https://openidconnect.net/
https://jwt.io/
https://oidcdebugger.com/debug
tools
2005
openid 1.0
2007
openid 2.0
2014
oidcopenid connect
vs
deprecated
authing
用户池是你用户系统的隔离的最小单位，你可以把不同场景的用户划分在不同的用户池。每个用户池下拥有自己的用户和应用程序，不同用户池之间的权限、应用、组织是完全隔离的。
what
我想为我的 C 端用户提供更好地身份认证体验
B2C
供应商
我想为我的 B 端客户提供更好地身份认证体验
B2B
员工
我想为企业管理员工身份。
B2E
用户池场景
user-pool
一个用户池可能会有多个应用，比如一个学校所有的学生在一个用户池里，而学校会同时开发了选课应用、邮箱应用、师生服务中心等多个应用，这些应用会使用同一个用户系统。
在 Authing 中每个应用都具备以下能力成为一个 OIDC 身份源；成为一个 OAuth 身份源；成为一个 SAML 身份源；通过配置登录注册方式、配置社会化登录、自定义 CSS 等方式自定义登录样式；开启注册协议；注册信息补全，详情请了解对认证流程进行扩展 - 注册时补全自定义字段数据；开启多因素认证；管理、授权 API 资源，详情请了解用户许可的资源授权；应用访问控制，控制哪些用户可以访问你的应用；子账号，添加子账号登录能力；登录状态管理，可以查看该应用当前在线的用户。
application
禁用cookie的影响
进而可以用 auhting 连接第三方Service Provider，如阿里云，AWS等
账密是在第三方
authing 可以作 Identity Provider
Identity Provider(Idp)
通过 OIDC、OAuth2.0、SAML、LDAP、AD 等标准协议去连接第三方 Identity Provider。
账密是在authing，提供给authing竞品、友商
authing 也可以作为 Service Provider
Service Provider
角色
Authing 支持多种标准协议进行联邦认证，你可以使用此应用快速体验 (opens new window)。
authentication
federation
is 一种安全理念
I 为 IAM（Identity and Access Management，身份识别与访问管理系统）
M 为 MSG（Micro-Segmentation，微隔离）
主流技术分为三种
zero-trust-network
sso(sign on & sign out)
基于 OAuth 2.0 框架的授权模式
使用权限 API
authorization
JWT Token
ID Token
authN vs authZ
concept
social idp
办公应用
oidc
saml
cas
标准协议应用(支持以下标准协议的idp)
企业idp
连接外部idp
使用应用密钥验证 HS256 算法签名的 Token
使用应用公钥验证 RS256 算法签名的 IdToken
验 idtoken
本地
POST https://<你的应用域名>.authing.cn/oidc/token/introspection
在线验证 OIDC AccessToken
GET https://<你的应用域名>.authing.cn/api/v2/oidc/validate_token
在线验证 OIDC IdToken
POST https://<你的应用域名>.authing.cn/oauth/token/introspection
在线验证 OAuth2 AccessToken
在线
如何验证用户身份凭证（token）
FAQS
guide
employees在AD目录
contractors用账密
2类用户
录入timesheet
user
审批timesheet
要双因子，因为审批的时间表涉及付款
2role
0
Identity-as-Service (\"IDaaS\
IDaaS
How to validate an ID Token
1.方案概览
dev-w69928oh.us.auth0.com
Connections允许的idp类型
设置client
2.auth0配置
cookie
client
auth0
identity provider
三层会话
可以使用 idtoken 的 expiration
也可以忽略 idtoken
都是通过cookie
How do I control the duration of the user's local application session? Can I drive that from Auth0?
How does Auth0's SSO session impact the application's session?
Session Management
client：清理client的cookie&session
auth0：重定向到 /auth0/logout，注销AUTH0用户，清理单点登录cookie
idp：可以做idp身份登出，但是一般不
三层会话的logout
user logout
普通用户
ad上的admin组
client上的admin组
管理员组
授权扩展组件
Access Control
3.Application Implementationclient实现
4.ASP.NET Core Implementation实现2
ExampleCo's
参考：https://curity.io/resources/learn/openid-connect-overview/
参考 & 案例
1.
is a security token
认证颁布方，https://etas.xiamenair.com.cn
工号、邮件、唯一id...
必须包含 client_id 作为audience value
还可以包含其他 identifier，即其他client_id?
一般是只有一个 audience
过期时间
可以留有余量，以防系统时钟偏差
格式同上
用户认证时间
如果要求了cliam，这个auth_time才是必选
string值，用于关联 a Client session 和本 id_token的值，防止重放攻击
1. RP 请求 OP的 /authorize 时带上（request入参）
2. OP 返回 /authorize 时带上（放在id_token）OP处理/token 的response时，是原封不动从 /authorize 请求中放到 id_token claim
3. RP 处理 /authorize 返回值时，比对如果id_token有此claim值（client收到 /token 的response时），client MUST 验证此值，与/authorize 带入的nonce参数一致
数据流向
另：容易混淆的3个概念
Authentication Context Class Reference
未定义预设的value，自由文本
Authentication Methods References，认证方式，如 账密或者是OTP（一次性的短信验证码）
amr
可以是是azp=aud，或1个azp+多个aud(含不含azp都可以)
Authorized party
azp
claims(id_token的)
required
optional
2. ID Token
3.1.1. Authorization Code Flow Steps
scope
response_type
client_id
redirect_uri
state (recommended)
response_mode（optional，oauth2标准里的）
a full User Agent page view
page
a popup User Agent window
popup
触屏界面
touch
a \"feature phone\" type display.？？？？
wap
display
MUST NOT display 任何 authN 或consent UI
如果未登录或request其他异常，return 1 个error code
This can be used as a method to check for existing authentication and/or consent.check authN 和 consent？
none
SHOULD 提示end-user重新登录
如果无法重新登录，MUST return error code，一般是 login_required
login
SHOULD 在返回信息给client之前，提示end-user进行consent同意
如果无法获得consent，MUST return error code，一般是 consent_required
consent
SHOULD 提示end-user选择一个账户
select_account
prompt
max_age
ui_locales
RP之前返回的id_token，作为这个request parameters，提示当前或过去的client登录session
如果这个id_token是已登录状态，或者这个reqeust登录完成，那么OP返回一个positive response，否则返回一个error，如 login_required
当prompt=None时，SHOULD 带上本参数（yoyo：否则如何验证所谓的“已登录”状态？），若没有带上，MAY 返回 error：invalid_request但即使没带上，OP也应该尽可能的校验当前登录状态（？）
本参数是 RP -> OP 的，但也无需把本token的 audience 设置成 OP
如果当初OP -> RP 返回的是加密的id_token，那么RP 需要：1. 解密，2. 重新加密(使用OP能够解密的key)，3. 传递重新加密后的id_token
id_token_hint
向OP提示end-user可能用于login的 id（yoyo：RP就可以用来预填好用户名）
login_hint
acr_values
3.1.2.1. Authentication Request
consent的事
3.1.2.4. Authorization Server Obtains End-User Consent/Authorization
response 一些信息，附加在redirect_uri里，作为query parameters（这些信息在oauth2 的 4.1.2 有描述）
3.1.2.5. Successful Authentication Response
response信息
3.1.2.6. Authentication Error Response
要validate response，要防止 CSRF
3.1.2.7. Authentication Response Validation
3.1.2. Authorization Endpoint
没有用JWE，就不用关注？
dicovery路由，返回的issuer，必须与JWT里的iss一致
The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim.
对比aud里，是不是含有自己的client_id
7. The alg value SHOULD be the default of RS256 or the algorithm sent by the Client in the id_token_signed_response_alg parameter during Registration.
必须在exp之前
9. The current time MUST be before the time represented by the exp Claim.
iat太久的，可以拒绝认可
nonce有传，就得验证
auth_time如果太久了，要求re-authentication
3.1.3.7. ID Token Validation(client 端验证id_token而不是server端验签的事)
3.1.3. Token Endpoint
3.1. Authentication using the Authorization Code Flow
3. Authentication
4. Initiating Login from a Third Party
5. Claims
6. Passing Request Parameters as JWTs
7. Self-Issued OpenID Provider
public
pairwise
2类
subject_types_supported
OP声明支持的 subject id types
subject_type
若OP支持2个type及以上，RP要在register时声明用的type
8. Subject Identifier Types
http basic authentication scheme
client_secret_basic
request_body
client_secret_post
Unique identifier for the token
client_secret_jwt
private_key_jwt
延伸话题
Client Authentication methodsclient请求/token时，传递client_id 和 client_secret的方式
9. Client Authentication
生产者(OP)，私钥1 对JWT进行签名
消费者(RP)，公钥1 解密)
JWS，signature
完整性，integrity消息不被篡改，让RP确认消息传送者真的是那个OP
生产者（OP），公钥2，加密
消费者（RP），私钥2，解密
JWE，encrypt
保密性，confidentiality让 RP 传送给 OP的消息，保密
若2者都有，需先签名，后加密
signature & encrypt
支持的signing 和 encryption 算法
用于RP的验签？
public key
OP在discovery中，公告
所需的signing 和 encryption 算法
用于OP的加密，回头RP好解密？
RP在dynamic registration中，声明
前言
非对称
对称
算法名定义在https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-algorithms
10.1. Signing
10. Signatures and Encryption
认证信息的
...20个
standard(userinfo 的)
at_hash
c_hash
sub_jwk
non-standard
claims
个人总结
openid core
openid discovery
openid dynamic registration
query
fragment
2.1. Response Modes
2.2. Multiple-Valued Response Types
2. Response Types and Response Modes
oauth2 multiple response types
oauth2 form post response mode
Final Specifications
补充了core1.0规范
定义：如何持续监控user在OP的登录状态
以便：user，OP -> RP 的联动 logout
本规范
1.1. Requirements Notation and Conventions
1.2. Terminology
1. introduction
什么pki 和 op的公钥？
如果已加密，则使用与 OP 协商好的 key和 算法进行解密
client 如何对/token返回的 id_token进行校验
TODO 具体如何得到并验证 id_token，参考core
RP的session开始于，\"RP验证了user的id_token之时\"
resonse标准参考core 3.1.2.5/6
注意区别于 state 字段， 是oauth2 里面的规范，用来防 CSRF的
client id
origin url
op user agent state
by
session_state生成可用于对比用户登录状态是否变化了
OP如果支持session mgmt，就must在 authentication response 里增加一个 \"session_state\" 的参数(如果是error，则是should)
2. creating and updating session
方案1不可行：通过重复提交 Authentication Request with 参数 prompt=none。缺点是network traffic大，在移动端难以实现
发送内容：Client ID + \" \" + Session State
MUST re-authentication with prompt=none
change
unchange
MUST NOT re-authentication with prompt=none，以免无限循环
error
收到 op_iframe 的返回
3.1. RP iframe
计算server的用户状态，并与 RP-iframe发来的session state 对比
3.2. OP iframe
check_session_iframeOP的discovery 提供的一个url，RP用来postMessage到 OP的OP地址url
3.3. OpenID Provider Discovery Metadata
方案2可行：从RP iframe 轮询访问一个 hidden OP iframe（with an origin restricted postMessage）
方案2
https://<IS_SERVER_HOST>:<IS_SERVER_PORT>/oidc/logout
oidc logout endpoint
https://<IS_SERVER_HOST>:<IS_SERVER_POST>/oidc/checksession?client_id=<CLIENT_ID>
oidc session iframe endpoint
在 OP 的 discovery 的 endpoint
参考
3. Session Status Change Notification目的：想持续知道OP上的user登录状态。
略
4. Validation
5.1. User Agents Blocking Access to Third-Party Content
5. Implementation Considerations
op iframe必须严格限制，postMessage请求调用者来自已知的rp，以防止XSS？
rp iframe必须严格限制，只处理来自op iframe的postMessage，以防止XSS
6. Security Considerations
7.1. OAuth Parameters Registry
7.2. OAuth Authorization Server Metadata Registry
7. IANA Considerations
Session Management 1.0
依靠end-user在OP的认证，在RP访问资源的持续时间段
session
session ID
1. Introduction
RP若支持http-base的logout，那么向OP注册时，可以登记一个 frontchannel_logout_uri URI
OP会在一个page里，render一个 src=frontchannel_logout_uri 的 iframe，去触发 RP 的 logout 行为
frontchannel_logout_uri
frontchannel_logout_uri 工作时（即OP render一个RP url的iframe），RP是否要求传入query parameter iss + sid
frontchannel_logout_session_required
OP 展示 iframe时，可以添加两个参数，iss、sid
RP可以 verify 这两个参数，即与id_token里的iss 和 sid 对比。若对比不符，则不进行RP的logout行为
iss、sid（注意是MAY，不是必须）
RP的response，必须要在header添加 Cache-Control: no-store，防止干扰后续的logout request
RP 本身也可以再当做一个OP，对二层RP提供登录状态，此时也要对二层RP进行logout（这个场景太复杂，不管了）
2. Relying Party Logout Functionality
于RP，表示在 user-agent或device上登录的一个 end-user
于OP，不同的sid表示OP上不同的会话
sid的内容对于RP是不透明的（yoyo：RP不需要知道sid的值如何生成，让OP去关心）
sid
总览
https://rp.example.org/frontchannel_logout
https://rp.example.org/frontchannel_logout ?iss=https%3A%2F%2Fserver.example.com &sid=08a5019c-17e1-4977-8f42-65a12843ea02
3.1. Example Front-Channel Logout URL Usage
3. OpenID Provider Logout Functionality
OP page上展示的RP iframe，可能会访问不到RP本地的一些浏览器信息，导致异常（因为域名当前是在OP上，与RP不一致）
4. Implementation Considerations
Front-Channel Logout 1.0
more reliable（不像front-channel 的 user-agent交互，一旦页面跳转开session是无法正常工作的）
优点
用不上cookie或local storage，RP和OP之间交互必须传递完整信息
RP 必须为 OP提供一个application-specific 的方法，用来结束 RP 的session(一旦接收到 OP的back-channle logout请求，就执行)（yoyo理解，遵循OP的logout契约，专门为它开发一个。若是front-channel，RP自己想怎么执行session terminate 都可以）
RP 的logout uri必须要被OP可访问，意味着，OP -> RP 的链路必须是可达的(外部rp会有些问题，必须让OP可访问所有外网或指定RP地址白名单？)
缺点
Logout Token新概念，JWT，similar to an ID Token that contains Claims about the logout action being requested.
1.2 Terminology
OP是否支持back-channel 登出
backchannel_logout_supported
是否支持OP带着sid作为参数，调用RP的logout
if true，OP最初返回的id_token 要包含着sid
backchannel_logout_session_supported
2.1. Indicating OP Support for Back-Channel Logout
url，当OP带着token请求此RP url，RP会将用户logout
backchannel_logout_uri
RP是否要求，当OP请求 backchannel_logout_uri 时，要在logout_token带上sid以便于区分此OP上的 RP session
backchannel_logout_session_required
2.2. Indicating RP Support for Back-Channel Logout
2.3. Remembering Logged-In RPs
OP 请求多个 RP logout时，发送的类似于id_token的jwt
如core的9所述
一个json object{ \"http://schemas.openid.net/event/backchannel-logout\": {}}以上json的member和value，表示此token为logout_token
events
sub(optional)
sid(optional)
MUST 包含 sub 或 sid claim，MAY 两者都有如果不带有 sid，那么目的是要所有RP上的session(符合 iss和 sub的end-user)全部 logout
MUST NOT，禁止使用 nonce claim。yoyo：为了避免与id_token 混淆
Logout Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored.
logout_token MUST 签名，MAY 加密，
2.4. Logout Token
OP post 请求back-channel logout url，触发RP logout
POST body 使用 application/x-www-form-urlencoded encoding，
OP 请求里必须带上logout_token参数，RP 用来识别需要logout的end-user
2.5. Back-Channel Logout Request
2.6. Logout Token Validation
通过 iss + sub 和(或) sid，定位找到 client的session id
清理 session id 对应的session（特定实现，？？）
如果当收到logout request是，识别到的end-user已经是logout状态，那么认为此logout 是成功的
本RP logout了，作为downstream的一个 OP，也传递logout信息到自己的下一级RP
downstream 级联logout
refresh_token 是否被销毁，取决于 offline_access 属性，如果有此属性，就无需销毁
2.7. Back-Channel Logout Actions
成功，RP返回 httpcode 200，注意可能会被web框架替换成204，所以OP应该把204也当做成功
请求若validate失败，或logout失败，RP返回 httpcode 400，MAY 包含一个 json object 的body，字段是 error(REQUIRED) 和 error_description(OPTIONAL)
SHOULD response的header，包含 Cache-Control: no-store，防止缓存
2.8. Back-Channel Logout Response
RP执行三步骤：validate->action->response
2. Back-Channel Logout
3. Implementation Considerations
logout_token 必须是签名的，以便RP可以验明logout_token的正身，防止“拒绝服务攻击”
logout_tokne expiration时间尽量短，2分钟左右，防止logout_token被捕获后重播
3.8. Validate Issuer and Subject
3.9. Use and Validate Audience
3.11. Use Explicit Typing
3.12. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs
参考IETF-jwt2.7. Cross-JWT Confusion
4.1 cross-jwt confusion
4. Security Considerations
todo 先略过
5.1. OAuth Dynamic Client Registration Metadata Registration
5.2. OAuth Authorization Server Metadata Registry
todo
5.3
5. IANA Considerations
Back-Channel Logout 1.0
Logout EndpointThe endpoint at the OpenID Provider that is the target of RP-Initiated Logout requests.OP提供的，RP-Initiated 方式调用的logout地址
1.2 Terminology
id_token_hint (RECOMMENDED)
logout_hint（OPTIONAL）
client_id（OPTIONAL）
post_logout_redirect_uri（OPTIONAL）
state（OPTIONAL）
ui_locales（OPTIONAL）
parameters
必须支持get ，post
此url的一些限制
end_session_endpoint（REQUIRED）
2.1. OpenID Provider Discovery Metadata
2. RP-Initiated Logout定义一个Logout Endpoint
post_logout_redirect_uris
3.1. Client Registration Metadata
3. Redirection to RP After Logout
4. Validation and Error Handlin
RP-Initiated Logout 1.0
Implementer’s Drafts
session mgmt和 front-channel logout，都是 front channel communication通过user agent，来做OP -> RPs 的logout 同步
RO，resource owner
RS，resource server
AS，authorization server
confidential client
public client
clientid
client sercret
AS需事先配置
roles
认证&资源方
response_type：表示授权类型，必选项，此处的值固定为\"code\"
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。
request
code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。
response
GET /authorize？
grant_type：表示使用的授权模式，必选项，此处的值固定为\"authorization_code\"
code：表示上一步获得的授权码，必选项。
redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
client_id：表示客户端ID，必选项。
校验
access_token：表示访问令牌，必选项。
bearer 仅需携带服务端下发的token即可，适用于https
mac 适用于非https，除了token，还多了一些信息
token_type：表示令牌类型，该值大小写不敏感，必选项，可以是 bearer 类型或 mac类型。(TODO 有啥区别？)
expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
POST /token
endpoints
用户或RS不信任的client
有用户参与，consent过程
适用于
authorization-code
response_type: token
1
2
3
implicit
grant_type：password
username
password
用户或RS信任的client（应该也是必须为 confidential client 吧?）
resource-owner-password-credentials
grant_type: client_credential
appid:foo
secret:password123
无用户参与
client credentials
5. assertion
4+1种flow
2 legged flows
3 legged flows
code
token
GET /authorize？
response_type授权类型
authorization_code
client_credentials
POST /token
grant_type授权模式
2 type
authorization code
1. AS 提供 introspection api，供校验token
2. RS 提供资源时，先访问 AS 该api，校验token
reference tokens需要内省机制来校验token(ETAS用此类)
形式可以是JWT token
self-contained tokens通过签名，自行校验
access token
refresh token
code & token
TODO form_post 是什么
撤销一个access_token
revocation
解决Token的描述信息不完整的问题。
Introspection
misc
oauth2.0协议
oauth2+oidc协议(重点摘录)
收藏
0 条评论
回复 删除
下一页
