OIDC其实并不是新技术，
它主要是借鉴OpenId的身份标识，
OAuth2的授权
和JWT包装数据的方式，
把这些技术融合在一起就是OIDC。
OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题；
OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。
OIDC的核心在于在OAuth2的授权流程中，一并提供用户的身份认证信息（ID Token）给到第三方客户端，ID Token使用JWT格式来包装，得益于JWT（JSON Web Token）的自包含性，紧凑性以及防篡改机制，使得ID Token可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了UserInfo的接口，用户获取用户的更完整的信息。
OIDC 主要术语
主要的术语以及概念介绍（完整术语参见http://openid.net/specs/openid-connect-core-1_0.html#Terminology）：
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。
OIDC 工作流程
从抽象的角度来看，OIDC的流程由以下5个步骤构成：
- RP发送一个认证请求给OP；
- OP对EU进行身份认证，然后提供授权；
- OP把ID Token和Access Token（需要的话）返回给RP；
- RP使用Access Token发送一个请求UserInfo EndPoint；
- UserInfo EndPoint返回EU的Claims。
注意这里面RP发往OP的请求，是属于Authentication类型的请求，
虽然在OIDC中是复用OAuth2的Authorization请求通道，
但是用途是不一样的，
且OIDC的AuthN请求中scope参数必须要有一个值为的openid的参数，
用来区分这是一个OIDC的Authentication请求，而不是OAuth2的Authorization请求。
Originally,
OAuth and OpenId are designed for different purpose:
OpenId for authentication and OAuth for authorization.
OpenId Connect is a unification of the two and serves for both,
but does not change their original functionalities. Keeping that in mind, you should be able to find out yourself. ;-)
No completely,
first, you need to use id_token to log in,
second, you will get a accessToken,
last, use accessToken to access data.