Computer Stuff

OpenID Connect: A Primer for Hackathons and App-Makers

The social factor has become an important dimension in how many web and mobile apps work today. Everything from providing a basic profile for a user to connecting with social media accounts requires some form of authentication. Unfortunately, if you've never worked with authentication systems, they can be a tad overwhelming and complex.

Fortunately, there are several frameworks and libraries built for you already that have this functionality builtin. If that's all you looking for, here they are. If you want to know how the authentication works, however, read on!

So what is OpenID?

OpenID is a identity standard on top of the OAuth 2.0 standard. OAuth provides two key components to your web applications: authentication and authorization (sometimes abbreviated as AuthN and AuthZ respectively). Authentication proves who you are, authorization proves what you're allowed to access. For example, if you're writing a mobile game, you will need both since you need to know who the player is and what parts of the app they can access. A random player should only be able to access parts related to the game whereas an admin should be given access to a more privileged set of features (like a banhammer).

The problem is that creating a secure authentication and authorization framework requires a lot of developer hours and lots of auditing to make sure that nobody can sneak through. OAuth is a open standard that enforces these with several libraries that implement it for you.

How does it work?

There are three parties to consider in an OpenID request: the user, the application, and the identity provider. When a user connects to your application, it presents a token (usually a cookie) that identifies itself. The application can present this token to the identity provider (or use some information given by the provider) to make an authentication decision.

Given this layout, there are three states this relationship can be in: a "cold" state (i.e. the user has never used the application before), an authenticating state, and an authenticated state.

Cold State

Suppose a user has never used the application before, they now connect for the first time to your fancy new app ( Now you made always require the user to be in an authenticated state, so upon seeing that they have presented no credentials, you need to make the call to authenticate them. Suppose that our identity provider in this case is Google. Google will provide you a URL to redirect the user to go through the authentication process. Before presents this URL to the user, it adds information like the app information and details on what type of information it wants. So after you assemble this URL, you redirect the user (that's a 302 for you HTTP nerds) to Google's authentication URL.

When the user gets connected to Google, they'll be asked to log into their Google account and usually will be asked to give permissions to your app. Once the user has logged in and consented to use your application, they are provided two pieces of information: an authorization code and an ID token. We'll focus on the ID token and I'll focus on the other part later. Google now is presenting this information to the client and instructing it to pass that information to using another redirect.

Authenticating State

Now we're back at the application a second time, only this time we now have an ID token that identifies the user. This ID Token is in the form of a Base64-encoded JSON Web Token (JWT). It's effectively a JSON object that contains three parts: (1) a header describing the encryption/signature formatting, (2) a JSON object with user information, and (3) a signature that verifies the legitimacy of the token. The token that the provider (Google in our case) provides would provide this token with user information and a cryptographic signature. This signature verifies that it actually came from Google and wasn't spoofed. So the process in the OpenID case of verifying the legitimacy of the first authentication involves looking at this JWT and verifying that it did indeed come from the provider you requested.

At this point, you set a cookie on the user's machine to remember who they are on subsequent requests. This could be a unique identifier tied to their session or even the JWT itself.

Authenticated State

From this point on, we maintain the user's authenticated state as long as they provide a valid cookie. There are other minutae that we can discuss here like revoking authentication or the case when a user revokes application permissions, but those are topics for another time.


There's one additional state I left out, what happens when the user is no longer authenticated to your app? At this point you now need to redirect the user back to the identity provider to verify who they are. Effectively, you treat reauthenticating as you would a "cold" user.

Why use OpenID?

Having a standard makes the process of authenticating users so much easier. Instead of having to work with a custom log in implementation for each user, you simply have to change small variables like the URL for redirection. It also removes a lot of the "easy to get wrong" details from your application that can cause security vulnerabilities and other bad bugs.

Photo credit: Alex Berger

Let me know what you think about this post by commenting, liking, sharing, or email me at

Windows 10 Digest: A Step in the Right Direction

Microsoft recently released Windows 10, an attempt at unifying the desktop and mobile experiences through a single unified interface. When it comes to mobile, Microsoft hasn't had the best of luck. Windows 8 (and 8.1) were attempts at bridging the two worlds of desktop and tablet but only optimizing for the merged cases. Windows 10 seems to be a drastic revisit of these assumptions. I did a fresh install of Windows 10 to see how the experience would be for the new user and here's what I found.

First Power On

Upon a fresh install of the system, you get a clean screen that explains in pretty human terms what you need to do to set up. There were a few nice features like Wi-fi network sharing (No more asking for passwords!), and individual customization of privacy preferences. The downs? There's still a merging of Microsoft accounts with the PC account which still feels really odd to use even with the nice sync features. The privacy defaults are also pretty alarming. One of the screens states (if you use the defaults) that Microsoft will use your keyboard input, pen input, voice, etc. to customize your experience. It seemed like a little much to me and the fact that a lot of the power features (like Cortana mentioned later) require this or a large set of them.

Desktop or Tablet?

One of the small features that made me really happy is the fact that you can really use Windows 10 as a desktop or tablet and it's seamless to transition between the two. I'm running Windows 10 on the Surface 3 and as soon as I flip the keyboard back (or disconnect it) it knows to switch to a tablet mode and optimize for that case.

Microsoft has also finally caught up with other systems and added Multiple Desktops to the Windows features set. However it's very minimal in the sense that it allows you to have multiple desktops, but doesn't have the nice features of swiping between them or being able to just peek at what's in another desktop without switching to it.

The start menu is also back, but not as you might remember it. On the desktop experience, you have a sort of mini start screen on the right hand side with what you typically think of as your traditional start menu on the left hand side. I find it's a nice compromise between the two interfaces and still gives you easy access to nice features like search and all apps (which also has it's niceties in the tablet mode start screen).


It's the nerd trump card and Microsoft played it well. Cortana appears to be more Microsoft's answer to Google Now than Siri. Occasionally it will show a message in the search box letting me know of an event or suggesting something I might like to know. The voice recognition technology is quite mature and detects most of my complex statements on the first try.

Unfortunately, it comes at a cost, Cortana requires a whole bunch of permissions to even begin working. Unlike Google Now which is fine using subset of the permissions, Cortana appears to request a large amount whether you use them or not. Immediately after starting it, I was asked to provide location access and input personalization before microphone input which seemed quite odd to me. I was only asked to provide microphone access once I tapped the new microphone icon that showed up.

On the bright side, Microsoft makes it easy to just use the normal search feature without enabling Cortana which was one of my favorite Windows 8 features.

Microsoft Edge

Edge feels like what Google Chrome used to be: simple, clean, and getting you exactly where you want to go. It's a really simple browser that just starts up and goes to where you want. Unfortunately you still have the zombie ruins of it's begrudged forefathers that refuse to render certain web pages. I'm not talking about sites that block rendering like WhatsApp, I'm talking about websites that should render like Google Play Music's web interface or even GitHub.

Edge appears to be going the same route as Chrome in the sense that it's starting out simple and will flex as demand decides. I'm looking forward to features like add-on support from Chrome and Firefox but it really feels like something that should've shipped with the browser as a default features. Because of this, it's really too early to tell and not all that useful in it's current state.

Overall Impression

I think Microsoft is definitely taking a better direction this time around. Some of it's ghosts from Windows 8(.1) are still haunting it like the assumption that everyone is a power user in some of the small feature details. For the first time in a while, I'm excited to see what Microsoft does with Windows from here and what's coming next.