How I Would Do OAuth 3.0

I want to preface this post by saying that this post is to test my understanding of OAuth 2.0 because I use OIDC at work all the time and have next to no understanding of how it works. This is a two part post. In this post, I’ll say how I would implement a similar system, then in the next post, I’ll write about all the things wrong with my design and how OAuth 2.0 handles the same problems.

I won’t dive deep into all the details because I only need to understand this at a high level. I won’t work on our authentication systems every day at work so I won’t go into all the details in the IETF RFC. After I save this post, I’m going to watch a few videos and skim the RFC, then poke holes in my design.

Problem Statement

I want to create a simple API for authenticating a user with my system. For this example, let’s say that I’m working on a videogame called Kitoshyk, but I don’t want to implement a secure system to authenticate my users. Instead, my system can trust Twitch’s authentication system. If Kitoshyk trusts Twitch, and Twitch trusts an end user, then Kitoshyk can transitively trust the end user. Let’s call the end user Kevin.

This picture states some of the steps I think should be there.

1. Kevin Gives Twitch an Email/Pass Combo

Kevin does a basic password and email authentication with Twitch. This assumes that he already has an account there and has verified his email. Now that he has connected to Twitch, he can receive a token.

2. Kevin Gets an OAuth Token

Twitch and Kitoshyk trust each other. The Twitch authentication API just gave Kevin a token specifically to be used to authenticate with Kitoshyk. There has to be some prior configuration to allow Kitoshyk to trust Twitch. So Kevin has a token ASD23452 along with an expiration date.

3. Kevin Presents Kitoshyk with a Token

So Kevin shows up to Kitoshyk with ASD23452.

4. Kitoshyk asks Twitch who the token is for

Kitoshyk takes that token and says, “Hey Twitch, I heard you generated ASD23452. Who is it for?” When Kitoshyk initiates the request to send to Twitch, Kitoshyk must also provide a signed certificate asserting that it’s Kitoshyk.

5. Twitch says who the token was generated for

Then Twitch says it’s for Kevin, then verifies the expiration date. Then Kitoshyk marks the token ASD23452 as used/expired and creates a new session token for Kevin that will last the duration of his authenticated session.

Problems I’d Predict

The biggest design problem I think that I would run into is network partitions between Kitoshyk and the Twitch Authentication API. If those two services can’t talk to each other, then no one will be able to authenticate, even if the client can talk to both services. It might be a better idea to use the client, Kevin, as a message bus and have all communication between Kevin, Kitoshyk, and Twitch go through Kevin.

If the trust relationship between Kitoshyk and Twitch expires, all Twitch authentication methods would fail for a short time.

That token that I mentioned isn’t encrypted. I only talk about these systems at 10,000ft level. The token should be longer and symmetrically encrypted. Otherwise, a token that short could be brute force generated. To design for that, the tokens given by Twitch could have short TTLs.