OIDC是OpenID Connect的简称,OIDC=(Identity, Authentication) + OAuth 2.0。它在OAuth2上构建了一个身份层,是一个基于OAuth2协议的身份认证标准协议。OAuth2是一个授权协议,它无法提供完善的身份认证功能,OIDC使用OAuth2的授权服务器来为第三方客户端提供用户的身份认证,并把对应的身份认证信息传递给客户端,且可以适用于各种类型的客户端(比如服务端应用,移动APP,JS应用),且完全兼容OAuth2,也就是说你搭建了一个OIDC的服务后,也可以当作一个OAuth2的服务来用。
OIDC的核心在于在OAuth2的授权流程中,一并提供用户的身份认证信息(ID Token)给到第三方客户端,ID Token使用JWT格式来包装,得益于JWT(JSON Web Token)的自包含性,紧凑性以及防篡改机制,使得ID Token可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了UserInfo的接口,用于获取用户的更完整的信息。
主要角色:
EU(End User):一个人类用户。
RP(Relying Party ): 用来代指OAuth2中的受信任的客户端,身份认证和授权信息的消费方;
OP(OpenID Provider):有能力提供EU认证的服务(比如OAuth2中的授权服务),用来为RP提供EU的身份认证信息;
ID Token:JWT格式的数据,包含EU身份认证的信息。
UserInfo Endpoint:用户信息接口(受OAuth2保护),当RP使用Access Token访问时,返回授权用户的信息,此接口必须使用HTTPS。
流程简述:
(1)RP发送一个认证请求给OP;
(2)OP对EU进行身份认证,然后提供授权;
(3)OP把ID Token和Access Token(需要的话)返回给RP;
(4)RP使用Access Token发送一个请求UserInfo EndPoint;
(5)UserInfo EndPoint返回EU的Claims。
OIDC对OAuth2最主要的扩展就是提供了ID Token。
ID Token是一个安全令牌,是一个授权服务器提供的包含用户信息(由一组Cliams构成以及其他辅助的Cliams)的JWT格式的数据结构。
字段 | 释义 |
---|---|
iss (Issuer Identifier) | 必须。提供认证信息者的唯一标识。一般是一个https的url(不包含querystring和fragment部分)。 |
sub (Subject Identifier) | 必须。iss提供的EU的标识,在iss范围内唯一。它会被RP用来标识唯一的用户。最长为255个ASCII个字符。 |
aud (Audience) | 必须。标识ID Token的受众。必须包含OAuth2的client_id。 |
exp (Expiration time) | 必须。过期时间,超过此时间的ID Token会作废不再被验证通过。 |
iat (Issued At Time) | 必须。JWT的构建的时间。 |
auth_time (AuthenticationTime) | EU完成认证的时间。如果RP发送AuthN请求的时候携带max_age的参数,则此Claim是必须的。 |
nonce | RP发送请求的时候提供的随机字符串,用来减缓重放攻击,也可以来关联ID Token和RP本身的Session信息。 |
acr (Authentication Context Class Reference) | 可选。表示一个认证上下文引用值,可以用来标识认证上下文类。 |
amr (Authentication Methods References) | 可选。表示一组认证方法。 |
azp (Authorized party) | 可选。结合aud使用。只有在被认证的一方和受众(aud)不一致时才使用此值,一般情况下很少使用。 |
ID Token通常情况下还会包含其他的Claims(毕竟上述claim中只有sub是和EU相关的,这在一般情况下是不够的,必须还需要EU的用户名,头像等其他的资料,OIDC提供了一组公共的cliams)。另外ID Token必须使用JWS进行签名和JWE加密,从而提供认证的完整性、不可否认性以及可选的保密性。
一个ID Token的例子如下:
{
"iss": "https://example.com",
"sub": "111",
"aud": "s6BbKhgqt7",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311280000,
"iat": 1311280000,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}
因为OIDC基于OAuth2,所以OIDC的认证流程主要是由OAuth2的几种授权流程延伸而来的:
①Authorization Code(授权码模式):使用OAuth2的授权码来换取Id Token和Access Token。
②Implicit (简化模式):使用OAuth2的Implicit流程获取Id Token和Access Token。
③Hybrid(混合模式):混合Authorization Code +Implicit。
Resource Owner Password Credentials Grant(密码模式)是需要用途提供账号密码给RP的,既然已经得到用户的用户名、密码了,便没必要再去获取ID_Token了。
Client Credentials Grant(客户端模式) 这种方式不需要用户参与,与用户身份认证并不兼容。
这也反映了授权和认证的差异,只使用OAuth2来做身份认证的事情是存在不足的。
这种方式使用OAuth2的Authorization Code的方式来完成用户身份认证,所有的Token都是通过Token EndPoint(OAuth2中定义:https://tools.ietf.org/html/rfc6749#section-3.2)来发放的。
构建一个OIDC的Authentication Request需要提供如下的参数:
以上这5个参数是和OAuth2相同的。除此之外,还定义了如下的参数:
以上是基于Authorization Code方式的OIDC的认证请求所需的参数。在OIDC的其他认证流程中也会有其他的参数或不同的参数值(稍有差异)。
示例请求串:
GET
/authorize?response_type=code&scope=openid%20profile%20email&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
HTTP/1.1
Host: server.example.com
在授权服务器接收到认证请求之后,需要对请求参数做严格的验证,具体的规则参见http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation,验证通过后引导EU(End User)进行身份认证并且同意授权。在这一切都完成后,会重定向到RP指定的回调地址,并且把code和state参数传递过去。
比如:
HTTP/1.1 302 Found
Location: https://client.example.org/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj
RP使用上一步获得的code来请求Token EndPoint,这一步同OAuth2,就不再展开细说了。然后Token EndPoint会返回响应的Token,其中除了OAuth2规定的部分数据外,还会附加一个id_token的字段。id_token字段就是上面提到的ID Token。例如:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache{
“access_token”: “SlAV32hkKG”,
“token_type”: “Bearer”,
“refresh_token”: “8xLOxBtZp8”,
“expires_in”: 3600,
“id_token”: “eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg”
}
在RP拿到这些信息之后,需要对id_token以及access_token进行验证(具体的规则参见http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation和http://openid.net/specs/openid-connect-core-1_0.html#ImplicitTokenValidation)。
Implicit (简化模式)的工作方式是在OAuth2 Implicit上附加提供id_token,认证请求的参数和基于Authorization Code(授权码模式)的流程稍有不同,具体的差异参考http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest。
Hybrid(混合模式)则相当于Authorization Code(授权码模式)+Implicit (简化模式)。
UserIndo EndPoint是一个受OAuth2保护的资源。在RP(Relying Party )得到Access Token后可以请求此资源,然后获得一组EU(End User)相关的Claims,这些信息可以说是ID Token的扩展,比如如果你觉得ID Token中只需包含EU(End User)的唯一标识sub即可(避免ID Token过于庞大),然后通过此接口获取完整的EU的信息。此资源必须部署在TLS(安全传输层协议)之上,
例如:
请求:
GET /userinfo
HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG
响应:
HTTP/1.1 200 OK
Content-Type: application/json
{ “sub”: “248289761001”, “name”: “Jane Doe”, “given_name”:
“Jane”, “family_name”: “Doe”, “preferred_username”: “j.doe”,
“email”: “[email protected]”, “picture”:
“http://example.com/janedoe/me.jpg” }
其中sub代表EU(End User)的唯一标识,这个claim是必须的,其他的都是可选的。