There have been a lot of discussions at work lately about authentication and authorization. To better contribute I took a great course from Udemy on the nuts and bolts of oath, and I’d like to hit the highlights here for y’all.

Before Twitter standardized OAuth, apps that wanted to connect to your other accounts had to ask for your password. This caused a myriad of problems and entropy. I once got to meet a guy who worked on this, Blaine Cook - and I explained to him how it worked. Oh to be young.

OAuth improves security by removing the need for passwords. OAuth lets APIs know which app is calling and ensures that it’s the real user. It also makes it easy to scale multifactor authentication types, the key to all of which is redirection to an OAuth server that can get secrets over secure channels and obfuscate them from insecure ones and 3rd parties.

An important distinction here is that OAuth is for apps to access APIs without knowing who the user is, just that their token is valid, whereas OpenID Connect is an extension of OAuth that allows us not just to access (like a hotel door key) but to identify (know who is at the door holding the key).

There are five roles in OAuth - these are not always separate apps or code, they are just distinct roles to be played.

1. The User - Resource Owner

2. The Device - User Agent

3. The Application - Client

4. Authorization Server

5. The API - Resource Server

There are two application types, confidential apps running on a server that can keep secrets, and public apps like mobile and single page applications that can’t. One great think that I liked about Okta was that when setting up an app it determines which type you are making and if its public, it does not even create a client secret or allow client credential calls. This started to give me clues about my own product as well as feelings of wanting to just buy Okta.

All of this results in the critical and familiar user consent screen that makes all of this possible.

The front channel is the browsers URL bar, and it can’t keep a secret. The back channel is anything that can call https, even fetch in the browser, and it can in many ways keep a secret. This distinction is important for OAuth. Clients who can’t keep a secret can use Proof Key for Code Exchange or PKCE (pronounced pixie) to communicate in secure ways, but it protects all clients from authorization code injection attacks.

Maybe the most useful part of the course for me was to revisit the details of the JSON Web Token. Going over these fields in detail gave me insight into the design that was need for my work solution. I really recommend this course for anyone who is looking to brush up on their OAuth skills, or learn to build these features for the first time.