OIDC认证授权协议核心
OIDC是在OAuth2的基础上做了一个身份认证层,以便于客户端知晓授权的终端用户(End User),在客户端获取access_token
的同时一并提供了一个用户的身份认证信息Id Token,它必须使用JWT格式。
OIDC几个关键术语
- EU End User的缩写,指的是 一个最终用户。
- RP Relying Party的缩写,指的是OAuth2中的受信客户端,身份认证和授权信息的消费方。
- OP OpenID Provider的缩写,指的是有能力提供EU认证的服务(比如OAuth2中的授权服务),用来为RP提供EU的身份认证信息。
其它还有一些术语,参见OIDC术语列表。
OIDC协议簇
OIDC包含了很多规范,最小的规范是 OIDC Core,下图是一个比较老的图,已经有点过时了,不过在一定程度上也能帮助你理解OIDC。
- Core OIDC核心,定义了OIDC的核心流程, 如何在 OAuth 2.0 之上的身份验证以及使用声明来传达有关最终用户(EU)的信息 。
- Discovery 定义客户端如何动态发现有关 OpenID 提供者(OP)的信息。
- Dynamic Registration 定义客户端如何动态注册到 OpenID 提供者。
- OAuth 2.0 Multiple Response Types 定义了几个特定的新 OAuth 2.0 响应类型。
- OAuth 2.0 Form Post Response Mode 定义如何通过User Agent使用 HTTP POST 自动提交的 HTML 表单值返回 OAuth 2.0 授权响应参数(包括 OpenID Connect 身份验证响应参数)。
- RP-Initiated Logout 定义RP如何向OP请求退出一个EU。
- Session Management 会话管理,用于规范OIDC服务如何管理Session信息。
- Front-Channel Logout 基于前端的注销机制,使得RP可以不使用OP的iframe来退出。
- Back-Channel Logout 基于后端的注销机制,定义了RP和OP之间如何通过交互来完成注销。
- OpenID Connect Federation 联合认证, 定义 OP 和 RP 集如何通过使用联合操作符建立信任。
- Initiating User Registration via OpenID Connect 定义
prompt=create
身份验证请求参数。
两个基于Web的RP实施指南
- Basic Client Implementer’s Guide 使用OAuth2授权码流来实现基于Web的RP的核心功能的简单子集
- Implicit Client Implementer’s Guide 使用OAuth2隐匿流来实现基于Web的RP的核心功能的简单子集
迁移规范
- OpenID 2.0 to OpenID Connect Migration 1.0 OpenID Authentication 2.0 是一种流行的身份验证联合协议, OpenID Connect 是 OpenID Authentication 的新版本,该规范定义了如何迁移到新的OpenID Connect。
还有一些草案正在孵化中,这里就不多介绍了。
OIDC核心流程
OIDC 被抽象为以下5个步骤,如图:
- ① RP(客户端)向 OpenID 提供者(OP)发送请求。
- ② OP 对最终用户进行身份验证并获得授权。
- ③ OP 使用 ID 令牌响应,通常是访问令牌。
- ④ RP 可以向 UserInfo 端点发送带有访问令牌的请求。
- ⑤ UserInfo 端点返回有关最终用户的claims。
对比OAuth2,RP就是OAuth2客户端,这个时候发送的请求不是授权请求了,而是认证(AuthN)请求;OP也就是OAuth2授权服务器,它需要在OAuth2的基础上提供EU(资源所有者)的claims以及身份认证令牌Id Token。
OIDC认证授权流程中必须包含授权范围
openid
。
Id Token
Id Token是OIDC的特有概念,它是一个包含用户信息(claims)的JWT令牌,如下所示:
eyJ4NXQjUzI1NiI6IlN4cXFkV1l4VDdCWnJkSC11VnBnQUhmWDJxMzRxUHl4eDRvblg2bXYtcUkiLCJraWQiOiJqb3NlIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJ1c2VyIiwiYXVkIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwiYXpwIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwiaXNzIjoiaHR0cDpcL1wvbG9jYWxob3N0OjkwMDAiLCJleHAiOjE2NTM2MjUxMjgsImlhdCI6MTY1MzYyMzMyOCwibm9uY2UiOiJXNm5LeTlxZnFWMkRvSDN1TDVGVGNVOUVGR2k4dWlqay1lcDIyV3RGQ2NZIn0.VDBOF867LnQIB52XGkSMT6hAu0NpyJsPA3soIAt3WWb4dwDmdiMrq5xpRuewURknmBmhZaJHT2QETEFWGhwB5gnq4kw4yPlvOpUuKxqfPsr9plA0HV_mQF9WFearRmVI12hGBrgj0Htgf4I5K6Nz8c4K0ibrdmcHSwonrb856TVep0Ne1cr21tOcmYmptgGco_vNsKvPsua0Hxff56_ikGDYonY5y7q6leFP5F9LAKUgRjPdhXM6OzdpHfP8XkiiPor9A1WWW0VhxmxCGe7dfQF_0QFYtmWnAymSS1PExUz4KdKGjPKtPanZe6ufym-5-ErSc-kH0mWi6AxvYt_5VQ
我们对头部和负载两个部分进行解码看一看。
头部:
{
"x5t#S256": "SxqqdWYxT7BZrdH-uVpgAHfX2q34qPyxx4onX6mv-qI",
"kid": "felord.cn",
"alg": "RS256"
}
头部包含了常规的JWT Header信息,符合JOSE规范。
负载:
{
"sub": "user",
"aud": "e2fa7e64-249b-46f0-ae1d-797610e88615",
"azp": "e2fa7e64-249b-46f0-ae1d-797610e88615",
"iss": "http://localhost:9000",
"exp": 1653625128,
"iat": 1653623328,
"nonce": "W6nKy9qfqV2DoH3uL5FTcU9EFGi8uijk-ep22WtFCcY"
}
从上面看,负载包含了一系列的claim,它们的含义如图:
如何进行OIDC认证
OIDC的认证流程主要是由OAuth2的几种授权流程扩展而来,有以下三种:
- Authorization Code Flow 基于OAuth2授权码流程进行OIDC认证授权
-
Implicit Flow基于OAuth2隐匿流,由于OAuth2.1移除了隐匿流,所以这个应该也会被移除。 -
Hybrid Flow基于以上两者的混合流,也应该会被移除。
至于为什么没客户端凭据模式,是因为客户端凭据被设计用来做客户端之间的交互和End User根本没用半毛钱关系。所以重点就是Authorization Code Flow。
Authorization Code Flow
关于授权码流,其实我觉得没有什么可多说的,如果你是OIDC Authorization Code Flow,你必须在请求中的scope
参数中携带openid
,授权服务器收到请求后会多返回一个EU的用户信息ID Token。流程上和OAuth2授权码流程完全一样。
请注意,OIDC必须使用JWT作为令牌风格。
用户信息端点
OIDC还提供用户信息端点,这个端点是一个资源端点。它的请求方式为:
GET /userinfo HTTP/1.1
Host: localhost:9000
Authorization: Bearer eyJ4NXQjUzI1NiI6IlN4cXFkV1l4VDdCWnJkSC11VnBnQUhmWDJxMzRxUHl4eDRvblg2bXYtcUkiLCJraWQiOiJqb3NlIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJ1c2VyIiwiYXVkIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwibmJmIjoxNjUzNTQ2OTUwLCJzY29wZSI6WyJvcGVuaWQiLCJtZXNzYWdlLnJlYWQiLCJtZXNzYWdlLndyaXRlIl0sImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo5MDAwIiwiZXhwIjoxNjUzNTQ3MjUwLCJpYXQiOjE2NTM1NDY5NTB9.MxySV9FwP3JVdThc7DkoROfseEPW1fRXRD1ljWN05keCzwaiAwvRap-QyA5gYJewpid7fOFwnD5ETDns3-ia_QHRYp5RIPWnc-cb__9_JITTpLso_AiXpwxCr6TxrKt5Ax_jzkL9_MGrHQl7BqUpCAecc_NccS4WAR6pmIiNexAMrXusn2a5VodFxv18BpgRv_dJ9w_a3tmYXBWAC1apSoXXlpaI96NIprXOUnJWyKGlYS1VsXc6YMYArDBOamvtFD74L9UaTLCj1n5GU1FKlTGE061c07eKFk91O9IgOc5YR0Uzu-VNhea0NB5SlwImhUJSE4Ab11RlJD_eg0Oc9g
也可以是POST请求。基本的返回值为:
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "felord.cn"
}
如果你还想返回比如邮箱地址、头像、昵称、真实姓名之类的用户信息,需要携带额外的scope
。
总结
OIDC还有很多东西,初学者掌握上面的基本功能即可,更多的功能需要参考OIDC官方文档。OIDC的用途比原生的OAuth2更加广泛,它是一个完全开放的标准,兼容了其它的一些IDP协议。后续在合适的时机,我会提到它们。
评论系统未开启,无法评论!