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）进行身份验证，并获取他们的身份验证信息。这种组合提供了一种灵活且安全的方式，让用户能够登录到各种应用程序，同时保护他们的隐私和数据安全。

统一登录

oauth2

SSO

OIDC

认证和授权

作者其他创作

大纲/内容

协议簇总览

complete

dynamic

minimal

core

discovery

dynamic client registration

session management

form post response mode

工作组

FAPI
Financial-grade API

MODRNA
Mobile Operator Discovery, Registration & autheNticAtion.

HEART
Health Relationship Trust

EAP
Enhanced Authentication Profile

SSE
Shared Signals and Events

eKYC-IDA
eKYC and Identity Assurance

terminology

认证(authN)

SSO

实现1：CAS

1.0

基础模式，适用于web

2.0

代理模式，适用于非web

实现2：OIDC

委托授权(authZ)
delegated authorization

用户

资源存储

第三方

其他

APIKEY

HMAC算法

JWT

3大块

header

alg

typ

payload

iss

https://etas.xiamenair.com.cn

sub

工号

aud

必须包含 client_id

exp

过期时间
可以留有余量，以防系统时钟偏差

iat

issued at签发时间

nbf

jti

其他可自定义

name

admin

nonce

auth_time

acr

....

signature

到目前为止，jwt的签名算法有三种。

对称加密HMAC【哈希消息验证码】：HS256/HS384/HS512

非对称加密RSASSA【RSA签名算法】（RS256/RS384/RS512）

ECDSA【椭圆曲线数据签名算法】（ES256/ES384/ES512）

可以放在

url

post body

header

两种实现方式

JWS
JSON Web Signature

签名，完整性

JWE
JSON Web Encryption

加密，保密性

其他概念

JWK/JWKS

定义

JSON Web Key (JWK) A JSON object that represents a cryptographic key.
The members of the object represent properties of the key, including its value.

JSON Web Key Set (JWKS) A JSON object that represents a set of JWKs.
The JSON object MUST have a keys member, which is an array of JWKs.

Auth0 exposes a JWKS endpoint for each tenant, which is found at https://YOUR_DOMAIN/.well-known/jwks.json.
This endpoint will contain the JWK used to verify all Auth0-issued JWTs for this tenant.

例子

member-common

alg

EC 或 RS
加密算法族

use

表明算法目的，sig (signature) 或 enc (encryption)

kid

member-RSA

mod

n：modulus

exp

e：exponent

JWA(JSON Web Algorithms)

JOSE(JSON Object Signing and Encryption)

对客OAUTH

CAS单点登录

TGT（Ticket Granting Ticket）

TGC（Ticket Granting Cookie）

is cookie

key:CASTGC

value

一个TGT 的 ID标识

ST（Service Ticket）

CAS为用户签发的访问某一service的票据，ST是TGT签发的。

cross 3概念

CSRF
cross-site request forgery

跨站请求伪造

XSS
cross-site script

跨站脚本攻击

CORS
cross origin resourse-sharing

跨域资源共享

tools

https://openidconnect.net/

https://jwt.io/

https://oidcdebugger.com/debug

openid 1.0

2005

openid 2.0

2007

oidc
openid connect

2014

参考 & 案例

authing

concept

what

authing

user-pool

what

用户池是你用户系统的隔离的最小单位，你可以把不同场景的用户划分在不同的用户池。
每个用户池下拥有自己的用户和应用程序，不同用户池之间的权限、应用、组织是完全隔离的。

用户池场景

B2C

我想为我的 C 端用户提供更好地身份认证体验

B2B

我想为我的 B 端客户提供更好地身份认证体验

供应商

B2E

我想为企业管理员工身份。

员工

application

一个用户池可能会有多个应用，比如一个学校所有的学生在一个用户池里，而学校会同时开发了选课应用、邮箱应用、师生服务中心等多个应用，这些应用会使用同一个用户系统。

在 Authing 中每个应用都具备以下能力

成为一个 OIDC 身份源；
成为一个 OAuth 身份源；
成为一个 SAML 身份源；
通过配置登录注册方式、配置社会化登录、自定义 CSS 等方式自定义登录样式；
开启注册协议；
注册信息补全，详情请了解对认证流程进行扩展 - 注册时补全自定义字段数据；
开启多因素认证；
管理、授权 API 资源，详情请了解用户许可的资源授权；
应用访问控制，控制哪些用户可以访问你的应用；
子账号，添加子账号登录能力；
登录状态管理，可以查看该应用当前在线的用户。

authentication

禁用cookie的影响

角色

Identity Provider(Idp)

authing 可以作 Identity Provider

进而可以用 auhting 连接第三方Service Provider，如阿里云，AWS等

账密是在第三方

Service Provider

authing 也可以作为 Service Provider

通过 OIDC、OAuth2.0、SAML、LDAP、AD 等标准协议去连接第三方 Identity Provider。

账密是在authing，提供给authing竞品、友商

Authing 支持多种标准协议进行联邦认证，你可以使用此应用快速体验 (opens new window)。

federation

zero-trust-network

is 一种安全理念

主流技术分为三种

S 为 SDP（Software Defined Perimeter, 软件定义边界）

I 为 IAM（Identity and Access Management，身份识别与访问管理系统）

M 为 MSG（Micro-Segmentation，微隔离）

sso(sign on & sign out)

authorization

基于 OAuth 2.0 框架的授权模式

使用权限 API

JWT Token

ID Token

authN vs authZ

guide

连接外部idp

social idp

企业idp

办公应用

标准协议应用(支持以下标准协议的idp)

oidc

saml

cas

FAQS

如何验证用户身份凭证（token）

本地

验 idtoken

使用应用密钥验证 HS256 算法签名的 Token

使用应用公钥验证 RS256 算法签名的 IdToken

在线

在线验证 OIDC AccessToken

POST https://<你的应用域名>.authing.cn/oidc/token/introspection

在线验证 OIDC IdToken

GET https://<你的应用域名>.authing.cn/api/v2/oidc/validate_token

在线验证 OAuth2 AccessToken

POST https://<你的应用域名>.authing.cn/oauth/token/introspection

auth0

ExampleCo's

2类用户

employees在AD目录

contractors用账密

2role

user

录入timesheet

admin

审批timesheet

要双因子，因为审批的时间表涉及付款

1.方案概览

IDaaS

Identity-as-Service ("IDaaS") is a cloud-based service for identity and access management. The offered services often include Single Sign-on (SSO), federated identity, password management, and more.

How to validate an ID Token

2.auth0配置

设置client

The main characteristics of an application in Auth0 are:

Name: The canonical name of the application. This is used to identify the application at the portal, emails, logs, and more.

Client ID (read-only): The unique identifier for the application. This is the ID used in the application when setting up authentication with Auth0. It is an auto-generated alphanumeric string.

Client secret (read-only): A string used to sign and validate tokens which will be used in the different authentication flows. It is auto-generated and it must be kept confidential.

Domain: The domain name assigned to the Auth0 account. The format of the domain is {account-name}.auth0.com or {account-name}.{location}.auth0.com, for example ExampleCo.auth0.com.

Callback URL: The URL where the user is redirected after they authenticate.

dev-w69928oh.us.auth0.com

Connections
允许的idp类型

Auth0 supports a vast variety of protocols and identity providers:

Social: Allow your users to log in using Google, Facebook, LinkedIn, Github, and many more.
Enterprise: Allow your users to log in using Active Directory, ADFS, LDAP, SAML-P, and many more.
Database connections: Create your own user store by configuring a new database connection, and authenticate your users using email/username and password. The credentials can be securely stored either in the Auth0 user store, or in your own database.
Passwordless authentication: Allow your users to login without the need to remember a password and use an authentication channel like SMS or email.

3.Application Implementation
client实现

Session Management

三层会话

client

auth0

identity provider

When developing a web application, you will therefore need to keep track of the fact that the user has logged in to your Web application.

You can do this by making use of a cookie-based session to keep track of the fact that the user has signed in, and also store any of the user related information or tokens.

How do I control the duration of the user's local application session?
Can I drive that from Auth0?

都是通过cookie

可以使用 idtoken 的 expiration

也可以忽略 idtoken

How does Auth0's SSO session impact the application's session?

user logout

三层会话的logout

client：清理client的cookie&session

auth0：重定向到 /auth0/logout，注销AUTH0用户，清理单点登录cookie

idp：可以做idp身份登出，但是一般不

Access Control

授权扩展组件

普通用户

管理员组

ad上的admin组

client上的admin组

4.ASP.NET Core Implementation
实现2

参考：https://curity.io/resources/learn/openid-connect-overview/

Final Specifications

openid core

2. ID Token

is a security token

claims(id_token的)

iss

认证颁布方，https://etas.xiamenair.com.cn

sub

工号、邮件、唯一id...

aud

必须包含 client_id 作为audience value

还可以包含其他 identifier，即其他client_id?

一般是只有一个 audience

exp

过期时间

格式是json数字的timestamp，UTC ,到 seconds

可以留有余量，以防系统时钟偏差

iat

issued at ,JWT 签发时间

格式同上

auth_time

用户认证时间

格式同上

如果要求了cliam，这个auth_time才是必选

nonce

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个概念

acr

Authentication Context Class Reference

amr

Authentication Methods References，认证方式，如账密或者是OTP（一次性的短信验证码）

未定义预设的value，自由文本

azp

Authorized party

可以是是azp=aud，或1个azp+多个aud(含不含azp都可以)

3. Authentication

3.1. Authentication using the Authorization Code Flow

3.1.1. Authorization Code Flow Steps

3.1.2. Authorization Endpoint

3.1.2.1. Authentication Request

scope

response_type

client_id

redirect_uri

state (recommended)

response_mode（optional，oauth2标准里的）

nonce

display

page

a full User Agent page view

popup

a popup User Agent window

touch

触屏界面

wap

a "feature phone" type display.？？？？

prompt

none

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？

SHOULD 提示end-user重新登录

如果无法重新登录，MUST return error code，一般是 login_required

consent

SHOULD 在返回信息给client之前，提示end-user进行consent同意

如果无法获得consent，MUST return error code，一般是 consent_required

select_account

SHOULD 提示end-user选择一个账户

如果无法获得用户进行的account selection choice, MUST return error code，一般是 account_selection_required

max_age

ui_locales

id_token_hint

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

login_hint

向OP提示end-user可能用于login的 id（yoyo：RP就可以用来预填好用户名）

acr_values

3.1.2.4. Authorization Server Obtains End-User Consent/Authorization

consent的事

3.1.2.5. Successful Authentication Response

response 一些信息，附加在redirect_uri里，作为query parameters
（这些信息在oauth2 的 4.1.2 有描述）

3.1.2.6. Authentication Error Response

response信息

3.1.2.7. Authentication Response Validation

要validate response，要防止 CSRF

3.1.3. Token Endpoint

3.1.3.7. ID Token Validation
(client 端验证id_token
而不是server端验签的事)

If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt the ID Token. If encryption was negotiated with the OP at Registration time and the ID Token is not encrypted, the RP SHOULD reject it.

没有用JWE，就不用关注？

The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim.

dicovery路由，返回的issuer，必须与JWT里的iss一致

The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience. The aud (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.

对比aud里，是不是含有自己的client_id

If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.

If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value.

6. If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature.

The Client MUST validate the signature of all other ID Tokens according to JWS [JWS] using the algorithm specified in the JWT alg Header Parameter.

The Client MUST use the keys provided by the Issuer.

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.

8. If the JWT alg Header Parameter uses a MAC based algorithm such as HS256, HS384, or HS512, the octets of the UTF-8 representation of the client_secret corresponding to the client_id contained in the aud (audience) Claim are used as the key to validate the signature.

For MAC based algorithms, the behavior is unspecified if the aud is multi-valued or if an azp value is present that is different than the aud value.

9. The current time MUST be before the time represented by the exp Claim.

必须在exp之前

10. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.

iat太久的，可以拒绝认可

11. If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request.

The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

nonce有传，就得验证

12. If the acr Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of acr Claim Values is out of scope for this specification.

13. If the auth_time Claim was requested, either through a specific request for this Claim or by using the max_age parameter, the Client SHOULD check the auth_time Claim value and request re-authentication if it determines too much time has elapsed since the last End-User authentication.

auth_time如果太久了，要求re-authentication

4. Initiating Login from a Third Party

5. Claims

6. Passing Request Parameters as JWTs

7. Self-Issued OpenID Provider

8. Subject Identifier Types

2类

public

pairwise

OP声明支持的 subject id types

subject_types_supported

若OP支持2个type及以上，RP要在register时声明用的type

subject_type

9. Client Authentication

Client Authentication methods
client请求/token时，传递client_id 和 client_secret的方式

client_secret_basic

http basic authentication scheme

client_secret_post

request_body

client_secret_jwt

iss

sub

aud

jti

Unique identifier for the token

exp

iat

private_key_jwt

none

延伸话题

10. Signatures and Encryption

前言

signature & encrypt

完整性，integrity
消息不被篡改，让RP确认消息传送者真的是那个OP

JWS，signature

生产者(OP)，私钥1 对JWT进行签名

消费者(RP)，公钥1 解密)

保密性，confidentiality
让 RP 传送给 OP的消息，保密

JWE，encrypt

生产者（OP），公钥2，加密

消费者（RP），私钥2，解密

若2者都有，需先签名，后加密

OP在discovery中，公告

支持的signing 和 encryption 算法

public key

用于RP的验签？

RP在dynamic registration中，声明

所需的signing 和 encryption 算法

public key

用于OP的加密，回头RP好解密？

10.1. Signing

非对称

对称

算法名定义在https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-algorithms

个人总结

claims

认证信息的

iss

aud

exp

iat

standard(userinfo 的)

...20个

non-standard

at_hash

c_hash

sub_jwk

openid discovery

openid dynamic registration

oauth2 multiple response types

2. Response Types and Response Modes

2.1. Response Modes

query

fragment

2.2. Multiple-Valued Response Types

oauth2 form post response mode

Implementer’s Drafts

Session Management 1.0

1. introduction

本规范

补充了core1.0规范

定义：如何持续监控user在OP的登录状态

以便：user，OP -> RP 的联动 logout

1.1. Requirements Notation and Conventions

1.2. Terminology

提到的terms都定义在各个RFC里，如6749,7230

2. creating and updating session

RP的session开始于，"RP验证了user的id_token之时"

TODO 具体如何得到并验证 id_token，参考core

什么pki 和 op的公钥？

client 如何对/token返回的 id_token进行校验

如果已加密，则使用与 OP 协商好的 key和算法进行解密

OP如果支持session mgmt，就must在 authentication response 里增加一个 "session_state" 的参数(如果是error，则是should)

resonse标准参考core 3.1.2.5/6

session_state生成
可用于对比用户登录状态是否变化了

注意区别于 state 字段，是oauth2 里面的规范，用来防 CSRF的

client id

origin url

op user agent state

3. Session Status Change Notification
目的：想持续知道OP上的user登录状态。

方案1不可行：通过重复提交 Authentication Request with 参数 prompt=none。缺点是network traffic大，在移动端难以实现

方案2可行：从RP iframe 轮询访问一个 hidden OP iframe
（with an origin restricted postMessage）

3.1. RP iframe

发送内容：Client ID + " " + Session State

收到 op_iframe 的返回

change

MUST re-authentication with prompt=none

unchange

error

MUST NOT re-authentication with prompt=none，以免无限循环

3.2. OP iframe

计算server的用户状态，并与 RP-iframe发来的session state 对比

3.3. OpenID Provider Discovery Metadata

check_session_iframe
OP的discovery 提供的一个url，RP用来postMessage到 OP的OP地址url

参考

方案2

在 OP 的 discovery 的 endpoint

oidc logout endpoint

https://<IS_SERVER_HOST>:<IS_SERVER_PORT>/oidc/logout

oidc session iframe endpoint

https://<IS_SERVER_HOST>:<IS_SERVER_POST>/oidc/checksession?client_id=<CLIENT_ID>

4. Validation

略

5. Implementation Considerations

5.1. User Agents Blocking Access to Third-Party Content

6. Security Considerations

op iframe必须严格限制，postMessage请求调用者来自已知的rp，以防止XSS？

rp iframe必须严格限制，只处理来自op iframe的postMessage，以防止XSS

7. IANA Considerations

7.1. OAuth Parameters Registry

7.2. OAuth Authorization Server Metadata Registry

Front-Channel Logout 1.0

1. Introduction

1.2. Terminology

session

依靠end-user在OP的认证，在RP访问资源的持续时间段

session ID

2. Relying Party Logout Functionality

frontchannel_logout_uri

RP若支持http-base的logout，那么向OP注册时，可以登记一个 frontchannel_logout_uri URI

OP会在一个page里，render一个 src=frontchannel_logout_uri 的 iframe，去触发 RP 的 logout 行为

frontchannel_logout_session_required

frontchannel_logout_uri 工作时（即OP render一个RP url的iframe），RP是否要求传入query parameter iss + sid

iss、sid
（注意是MAY，不是必须）

OP 展示 iframe时，可以添加两个参数，iss、sid

RP可以 verify 这两个参数，即与id_token里的iss 和 sid 对比。若对比不符，则不进行RP的logout行为

RP的response，必须要在header添加 Cache-Control: no-store，防止干扰后续的logout request

RP 本身也可以再当做一个OP，对二层RP提供登录状态，此时也要对二层RP进行logout（这个场景太复杂，不管了）

3. OpenID Provider Logout Functionality

总览

sid

于RP，表示在 user-agent或device上登录的一个 end-user

于OP，不同的sid表示OP上不同的会话

sid的内容对于RP是不透明的（yoyo：RP不需要知道sid的值如何生成，让OP去关心）

3.1. Example Front-Channel Logout URL Usage

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

4. Implementation Considerations

OP page上展示的RP iframe，可能会访问不到RP本地的一些浏览器信息，导致异常（因为域名当前是在OP上，与RP不一致）

Back-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地址白名单？)

1.2 Terminology

Logout Token
新概念，JWT，similar to an ID Token that contains Claims about the logout action being requested.

2. Back-Channel Logout

2.1. Indicating OP Support for Back-Channel Logout

backchannel_logout_supported

OP是否支持back-channel 登出

backchannel_logout_session_supported

是否支持OP带着sid作为参数，调用RP的logout

if true，OP最初返回的id_token 要包含着sid

sid

2.2. Indicating RP Support for Back-Channel Logout

backchannel_logout_uri

url，当OP带着token请求此RP url，RP会将用户logout

backchannel_logout_session_required

RP是否要求，当OP请求 backchannel_logout_uri 时，要在logout_token带上sid以便于区分此OP上的 RP session

2.3. Remembering Logged-In RPs

2.4. Logout Token

OP 请求多个 RP logout时，发送的类似于id_token的jwt

claims

iss

aud

iat

jti

如core的9所述

events

一个json object
{
"http://schemas.openid.net/event/backchannel-logout": {}
}
以上json的member和value，表示此token为logout_token

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.5. Back-Channel Logout Request

OP post 请求back-channel logout url，触发RP logout

POST body 使用 application/x-www-form-urlencoded encoding，

OP 请求里必须带上logout_token参数，RP 用来识别需要logout的end-user

RP执行三步骤：validate->action->response

2.6. Logout Token Validation

2.7. Back-Channel Logout Actions

通过 iss + sub 和(或) sid，定位找到 client的session id

清理 session id 对应的session（特定实现，？？）

如果当收到logout request是，识别到的end-user已经是logout状态，那么认为此logout 是成功的

downstream 级联logout

本RP logout了，作为downstream的一个 OP，也传递logout信息到自己的下一级RP

refresh_token 是否被销毁，取决于 offline_access 属性，如果有此属性，就无需销毁

2.8. Back-Channel Logout Response

成功，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，防止缓存

3. Implementation Considerations

4. Security Considerations

logout_token 必须是签名的，以便RP可以验明logout_token的正身，防止“拒绝服务攻击”

logout_tokne expiration时间尽量短，2分钟左右，防止logout_token被捕获后重播

4.1 cross-jwt confusion

参考IETF-jwt
2.7. Cross-JWT Confusion

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

5. IANA Considerations

5.1. OAuth Dynamic Client Registration Metadata Registration

backchannel_logout_uri

backchannel_logout_session_required

5.2. OAuth Authorization Server Metadata Registry

backchannel_logout_supported

backchannel_logout_session_supported

5.3

todo

RP-Initiated Logout 1.0

1.2 Terminology

Logout Endpoint
The endpoint at the OpenID Provider that is the target of RP-Initiated Logout requests.
OP提供的，RP-Initiated 方式调用的logout地址

2. RP-Initiated Logout
定义一个Logout Endpoint

parameters

id_token_hint (RECOMMENDED)

logout_hint（OPTIONAL）

client_id（OPTIONAL）

post_logout_redirect_uri（OPTIONAL）

state（OPTIONAL）

ui_locales（OPTIONAL）

此url的一些限制

必须支持get ，post

2.1. OpenID Provider Discovery Metadata

end_session_endpoint（REQUIRED）

3. Redirection to RP After Logout

3.1. Client Registration Metadata

post_logout_redirect_uris

4. Validation and Error Handlin

5. Implementation Considerations

6. Security Considerations

oauth2.0协议

roles

RO，resource owner

RS，resource server

AS，authorization server

client

2类

confidential client

public client

AS需事先配置

clientid

client sercret

4+1种flow

authorization-code

endpoints

GET /authorize？

request

response_type：表示授权类型，必选项，此处的值固定为"code"

client_id：表示客户端的ID，必选项

redirect_uri：表示重定向URI，可选项

scope：表示申请的权限范围，可选项

state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

response

code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。

state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

POST /token

request

grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"

code：表示上一步获得的授权码，必选项。

redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。

client_id：表示客户端ID，必选项。

response

access_token：表示访问令牌，必选项。

token_type：表示令牌类型，该值大小写不敏感，必选项，可以是 bearer 类型或 mac类型。(TODO 有啥区别？)

bearer 仅需携带服务端下发的token即可，适用于https

mac 适用于非https，除了token，还多了一些信息

expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。

refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。

scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

适用于

confidential client

用户或RS不信任的client

有用户参与，consent过程

implicit

endpoints

GET /authorize？

request

response_type: token

response

适用于

public client

resource-owner-password-credentials

endpoints

POST /token

request

grant_type：password

username

password

response

适用于

用户或RS信任的client（应该也是必须为 confidential client 吧?）

client credentials

endpoints

POST /token

request

grant_type: client_credential

appid:foo

secret:password123

response

适用于

confidential client

无用户参与

5. assertion

跨域场景,A 做授权，B认可A的授权结果

2 type

response_type
授权类型

GET /authorize？

code

token

grant_type
授权模式

POST /token

authorization_code

password

client_credentials

code & token

authorization code

access token

reference tokens
需要内省机制来校验token(ETAS用此类)

1. AS 提供 introspection api，供校验token

2. RS 提供资源时，先访问 AS 该api，校验token

self-contained tokens
通过签名，自行校验

形式可以是JWT token

refresh token

misc

TODO form_post 是什么

endpoints

revocation

撤销一个access_token

Introspection

解决Token的描述信息不完整的问题。

 收藏

立即使用

oauth2+oidc协议(重点摘录)

figo

职业：暂无

去主页





0 条评论

下一页

为你推荐

查看更多

