OAuth and OpenID Connect

This is one article written as part of my studies for the CompTIA Security+ exam. (SY0-601) Make me better by commenting below.

OAuth enables you (user) to authorize some of your identity information to an OAuth-enabled service without giving the OAuth-enabled service your password for the Identity Provider (which is hosting your identity information) . At about 15:00 minutes into the video in [1] is a good diagram that walks through this.

  • Resource Owner – User (like me), who has the ability to say yes or no to sharing data
  • Client – service
  • Authorization Server – System that the user uses to authorize/approve sharing the data
  • Resource Server – System or API that holds my data that the client wants
  • Authorization Grant – Grant that says the user said yes. There are various types of grants (see RFC 6749, Section 4.1)
  • Redirect URI/Callback – After the user clicks yes, where do I go back to the client
  • Access token – How the client gets access to the Resource Server, the client exchanges the Authorization code for an Access Token. This is attached to the messaging to the Resource Server. The token has the authorized scopes.

Access Control

Scopes are not Attribute Based Access Control. More Discretionary Access Control….
Scopes are granted per client. I think that’s important to call out. I did not come across explicit definition of the access control method provided by OAuth scopes. Based on my understanding, the OAuth 2.0 framework provides for Discretionary Access Control. This is based on the requirement that the user is granting access to its resources. This seems similar to a Linux user chmod’ing a file to give another user access.

I have asked the question to the stackoverflow community and will update based on the responses there.

Channels

Interesting that the protocol is divided into front channel (in the browser) messaging and then more secure back channel messaging. The exchanging of the authorization code for the access token is over the back channel, a secret key was exchanged/established between the client and the resource server ahead of time to allow for secure transmit of the authentication grant and the access token. During the token exchange, the secret key is passed.

Authentication v Authorization

OAuth wasn’t designed for authentication but sites started using it for this purpose. It is for authorization. There’s no way to get the user ID. In other words, services were using OAuth for authenticating of a user but the service wasn’t able to get the authentication information (so they added hacks).

OpenID Connect was a layer added onto OAuth 2.0 to adapt OAuth 2.0 for the authentication. The ID token represents information about the user and was added. Now I can get an access token and an ID token. OAuth messaging is used for OpenID. The ID Token is in JavaScript Object Notation Web Token (JWT) format. The JWT has a signature portion for ID Token integrity.

References

  1. OAuth 2.0 and OpenID Connect (in plain English) – Easy to follow video from OktaDev.
  2. Decipher JWTs
  3. RBAC v ABAC
  4. RFC 7519 – JSON Web Token (JWT)
  5. RFC 6749 – Access Token Scopes

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s