OIDC is not actually a new technology.
It mainly draws on the identity of OpenId,
Authorization for OAuth2
and the way the JWT wraps the data,
Bringing these technologies together is OIDC.
OAuth2 provides Access Token to solve the problem of authorizing third-party clients to access protected resources ;
On this basis, OIDC provides ID Token to solve the problem of third-party client identification user authentication .
The core of OIDC is that in the OAuth2 authorization process, the user's identity authentication information (ID Token) is provided to the third-party client . The ID Token is packaged in JWT format, thanks to the self-contained nature of JWT (JSON Web Token). The security, compactness and tamper-proof mechanism make ID Token safe to pass to third-party client programs and be easily verified. In addition, the interface of UserInfo is provided, and the user can obtain more complete information of the user.
Key OIDC Terms
Main terminology and concept introduction ( see http://openid.net/specs/openid-connect-core-1_0.html#Terminology for full terminology):
EU : End User: A human user.
RP : Relying Party, used to refer to the trusted client in OAuth2, the consumer of identity authentication and authorization information;
OP : OpenID Provider, capable of providing EU authentication services (such as the authorization service in OAuth2), to provide EU identity authentication information for RP;
ID Token : Data in JWT format, including EU identity authentication information.
UserInfo Endpoint : User information interface (protected by OAuth2), when the RP uses Access Token to access, it returns the information of the authorized user. This interface must use HTTPS.
OIDC workflow
From an abstract point of view, the OIDC process consists of the following 5 steps:
- The RP sends an authentication request to the OP;
- OP authenticates EU and then provides authorization;
- OP returns ID Token and Access Token (if needed) to RP;
- RP uses Access Token to send a request UserInfo EndPoint;
- UserInfo EndPoint returns the EU's Claims.
Note that the request sent by the RP to the OP is an Authentication type request.
Although the Authorization request channel of OAuth2 is reused in OIDC,
But the use is different,
And the scope parameter in the AuthN request of OIDC must have a parameter whose value is openid ,
Used to distinguish that this is an OIDC Authentication request , not an OAuth2 Authorization request.
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.