The Acutual OAuth2.0

In my previous post, I gave an extremely simple hypothesis on how OAuth2.0 is designed. The exercise was the prime my mind for when I actually read about the Auth Flow. Now, I’ll give a high level overview of the actual protocol, then compare it to the post I made before. I want to talk about all the things that I didn’t design for.

The Actual Flow

The actual OAuth flow has 6 major steps in the IETF Protocol Flow, which summarizes the major steps required. I’m going to translate the doc into my own words and add extra context in around the different services to make the example concrete.

In my last post, I talked about Kevin authenticating with Kitoshyk using Twitch as an Identity Provider. I didn’t know about the role that OAuth2.0 plays in the OIDC flow, so I’ll add that information in as well.

There are 6 arrows in the diagram above. To make this simple, I’ll cover each of those arrows from top to bottom in the next 6 bullets.

• After arriving at the Kitoshyk website, Kitoshyk asks Kevin if he will “Grant Access” to Twitch to read my user info (more on this later).
• Kevin accepts. To accept it, he authenticates with the Authorization server and grants Kitoshyk permission to request his user information from Twitch.
• The Client goes to the Authorization server with the Grant and Scopes.
• The Authorization Server(Twitch) returns an API Token that Kitoshyk can use to do all the operations defined in the Scope. If this is an OIDC request, an extra JWT is returned so that Kitoshyk can read extra information about Kevin
• Kitoshyk now has a token that it can use to interact with Twitch. It’ll make every requrest with the Authorization: Bearer XXX header.
• Twitch returns any information (within scope) that Kitoshyk requests.

There are a few things that I don’t think I understand. It wasn’t clear in the IETF doc how Kevin authenticates with Twitch. I think it would be intuitive if he authed with Twitch when he grants access, but that step wasn’t clear in the doc.