How-to: OpenID Connect Authentication for OAuth

qtq80-UczEt6

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

Aric Day

Aric Day

Aric is based in Minneapolis, MN and has been managing Enterprise API programs for more than 10 years as both an operations sysadmin and an api security consultant designing api integration standards. He currently serves Layer7 North American core accounts within the central and western regions. In previous roles he has worked as an automation and api security consultant with both Accenture and Best Buy. Aric has an engineering degree from the University of Minnesota. He is active as a youth hockey coach in winter and enjoys getting outdoors during the brief MN summer months.

Share With Your Network

Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on email
Email
Share on print
Print

More From The API Academy

Scroll to top

REGISTER FOR THE API ACADEMY

Get exclusive content, webcasts, how-to videos, and event invitations