All Things Auth - A Look at AuthN, AuthZ, and OAuth

May 29, 2025#Software Development
Article
Author image.

Sarah Dutkiewicz, Senior Trainer

Have you ever wondered what is going on when you click that “Sign in with… ” button?

Single Sign-On with Google, Facebook, Apple, X, and email

What is authentication and authorization? How does OAuth tie into this?

I talk about all of these things in this webinar:

However, I know not everyone prefers video, so let’s talk about some of the concepts we covered in the webinar.

Authentication

What is authentication? Authentication - commonly abbreviated as AuthN - is when you are proving that the user or client is who they claim to be. Think of this as “Are you really who you say you are? Prove it!”

A factor is something that can be used in testing your identity. When proving your identity, there are 5 main categories to test:

  • Knowledge factors - “Things You Know” - such passwords, PINs, answers to security questions
  • Possession factors - “Things You Have” - such as a mobile phone, smartcard, security fob, passkeys, time-based one-time password (TOTP)
  • Inherence factors - “Things You Are” - such as fingerprints, irises, other biometrics
  • Location factors - “Where You Are” - such as geographic coordinates and proximity to wi-fi
  • Behavioral factors - “Things You Do” - such as gait and mouse movements

You may have heard of factors in terms of the abbreviations 2FA and MFA. Multi-factor authentication (MFA) means that you’re challenged by at least 2 factors during the authentication process. Two-factor authentication (2FA) is a subset of MFA, requiring specifically 2 factors during the authentication process.

The more you want to protect your data, the more you will want to choose more reliable or secure factors. For example, with password fatigue, it’s easy to get compromised username and password credentials. However, it would be more likely that someone is who they claim to be with a biometric scan.

Authorization

What is authorization? Authorization - commonly abbreviated AuthZ - is when you are proving that you have the right permission to access a resource. Where authentication is “Who are you?”, authorization is “Are you allowed to do this?” Once we know you are really who you claim to be, we need to make sure you’re allowed to access whatever you’re trying to get. Sometimes, this means checking a user’s privileges. It might be checking a user’s role. It might be checking a policy.

In our Identity Essentials course, I discuss authentication versus authorization in common scenarios and how they differ.

OAuth

What is OAuth? OAuth - short for Open Authorization - is an open authorization framework and an Internet standard. If you are interested in the official documentation, read RFC 6749: The OAuth 2.0 Authorization Framework. It enables third-party applications to access resources without exposing the user’s credentials. It was harder to implement OAuth 1.0 in 2007 - and impossible for mobile apps and JavaScript apps. However, OAuth 2.0 came out in 2012 and made it more approachable for implementation. There are different workflows for authorization, including:

  • Authorization Code Grant - gain an access token after authorization
  • Device Code Grant - gain an access token after the user consents to a device being used via a web page or another device
  • Client Credentials Grant - used for machine-to-machine interactions

An example of OAuth in action is when you want to connect a device - such as a mobile phone, gaming console, or a kiosk - to another system. Suppose you are trying to log into an app on your phone, it might give you a URL and code to enter to consent that this device can access the resource. The device code verification screen may look like this:

Device code verification screen for Google - shows a sample device code of QYL=XMM-GGF

The consent screen would look something like this:

OAuth consent screen for a device to access a Google Account

We walk through this device code example using HTTP files as part of our Identity Essentials course.

There are other flows as well. However, those get deprecated in OAuth 2.1, which is currently in discussion. You can learn more with this Draft proposal of OAuth 2.1. In addition to deprecating weaker OAuth 2.0 flows, there are other changes that are coming. Unfortunately, when some people implement OAuth, they still manage to put information in URL query strings. Thankfully, OAuth 2.1 will put an end to that.

About “Sign in with… ”

In our ASP.NET Identity in Action course, I walk you through how to set up eShopOnWeb so you can log into it using GitHub through OAuth. I chose GitHub specifically since our audience is commonly developers, and most have GitHub accounts. The implementation of “Sign in with…” could be OAuth.

It could also be implementing using something called OpenID Connect (OIDC). OIDC is a protocol built on top of OAuth 2.0 that adds an authentication component to the flows. It allows applications to verify the user identity and get profile information. This makes it easy to implement single sign-on support with these external providers.

At the time of course creation, GitHub did not support OpenID Connect. So the eShopOnWeb implementation is using just OAuth.

Additional Resources

If you think implementing these concepts in .NET are scary, we have some resources to share with you to make authentication, authorization, and OAuth more approachable:


Copyright © 2025 NimblePros - All Rights Reserved