Open ID Connect, OAuth and What Does It Mean?

Photo by Dan Nelson on Unsplash

The principles behind SAML, OAuth, Open ID Connect (OIDC) are all straight forward.

The specifications are very well specified ;-). There are some great starter projects, NuGet packages and samples available… But as with all things “authentication” they are poorly contextualised. It is easy to put a whole bunch of stuff into a solution you don’t need.

Whenever I delve into some “auth” work, the key points that are never clear are:

  • Is the code for “publishing an identity server” or “client” style solution?

So, I am putting together a few pages to try and help demystify some of this, and help others get into OAuth and OIDC solutions with understanding. If you have suggestions / ideas on how to improve the pages please comment.

These pages are not to give a full explanation of OAuth and OIDC, nor provide flow diagrams (shock horror)… It is more aimed at someone who has heard of OAuth and OIDC and now wants to use it in anger. So, I am trying to present this subject from a different angle that will hopefully make it easier to implement these standards in the real world.

The examples pages are quite detailed, but I hope I have brought out the “why” in the code and commands to help utilise the right bits of the standards and technology. It also means there will be some very obvious statements for many readers… sorry!

Golden rule for OAuth

Don’t cross the streams (or flows in this case) — focus on the one you want to use. Think about:

  • Context — are you: Pre or post Access token?

Here be dragons… misnome of simplicity

A good developer is fully capable of using OAuth and OIDC, and reading all the RFCs (some of which include great best practice guidance). A number of the RFCs repeat phrases such as : “this specification focuses on client developer simplicity and requires only an HTTP client and JSON parser, which are nearly universally available in modern development environments” (from RFC 8693 section 1)

Repeating the same thing, over and over, doesn’t make it true! Every element of the standard has proviso’s and MUST / SHOULD statements about checks that SHOULD take place before trusting a request or response. This means that you can’t just parse some JSON and use the data — you have to validate it, apply context, etc.

Part of the drive for these pages is to show some standard (mostly Microsoft biased) libraries that wrapper this complexity and provide secure implementations. This, in turn, should deliver the power and safety you expect from OAuth and OIDC.

What can I use OAuth & OIDC for?

Far too many things actually, but I’ve focused on three high level scenarios:

Three options. Single page app with facebook, or client server web app accesing Facebook data, or system to system
Three scenarios
  • Create a single page app that is authenticated by Facebook / google. Etc.

Other use case examples:

  • Build a full web app with client and server aspects

OAuth provides you the framework to do any of the above and many more variants — but it is a framework, you must plan carefully to wire it all up.

OAuth is in TWO Parts

Sounds obvious… when you are dabbling with APIs, you often “just want to call an API”… You can’t do that with OAuth. It boils down to:

  • Getting an Access Token (authorisation)

Getting an Access Token

This is the really complex part, and there are so many options on how to design your authorisation and retrieve the token. Your choices at this point are focus around:

  • Selecting the most secure way, for your chosen application architecture, to obtain an access token

Using your Access Token

Now that you’ve been granted access, time to make use of it. Attach the access token to every API call (usually in the Authorization header as a Bearer token).

Generally there are no complex authorisation rules applied now — you have your Access Token. You can get rejected when you try and access something that hasn’t been granted by your access token, but the complex calculations were done and the results stored.

Main Links & Further Reading

Orientation of terms

I’ve created page to help you orientate yourself with the basic terms: OAuth — orientation and terms

Worked example pages

A few to start with:

The key references are the standards themselves:



I have worked as an independent IT Consultant for 21 years. I excel at bringing together and architecting complex solutions, and delivering them.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aubyn Crawford

I have worked as an independent IT Consultant for 21 years. I excel at bringing together and architecting complex solutions, and delivering them.