As we know by now, the OAuth 2.0 protocol was built for authorization, not authentication. It excels at delegated authorization. Log in with Google? Sure. The OAuth protected API endpoint never sees your Google username and password. It doesnâ€™t need to know who you are. In fact, like a discreet bouncer at an exclusive club, it prefers not to. That shiny OAuth access token you present is all the API endpoint needs. Just flash it, and the door opens. No questions about your identity asked. Come on in.
This, of course, can cause problems.
Within the OAuth 2.0 protocol, there is no way to verify (authenticate) that the bearer of the access token is the one who originally received it. The access token contains no user information. Whoever presents the access token is considered trusted and authorized. This trust leaves the transaction between the API endpoint and the access token vulnerable to a man-in-the middle attack.
The OpenID Connect protocol is an extension of OAuth 2.0 and works not only to eliminate this vulnerability, but also to fill in the rest of the authentication gaps within OAuth 2.0, such as better enabling SSO. Within the Authorization flow, if â€œopenidâ€ is included as the scope, an additional ID Token is generated along with the Access token. The ID Token acts like an encrypted fingerprint that travels through the flow with the access token. At the API endpoint, It can be decoded to reveal user information for identity verification. A userInfo endpoint can also be referenced to reveal further user information.
So now the bouncer at the club sees your access token, but also checks your photo id at the door: authorization and authentication.
The accompanying video uses one of the two Layer7 OTK OpenID test clients (Basic Client Profile) to take you through the authorization and authentication flow. The required scope â€œopenidâ€ is included in the initial request. An access token and an ID token in JWT (JSON Web Token) format is issued.
blog written by Simon Crum