Table of contents
- What is OAUTH
- A trip to OAUTH1.0Ville
- What is OAUTH2.0
- Examples of OAUTH Technology
- OIDC
- Hands-on Implementation with Microsoft Entra ID
What is OAUTH
OAUTH is a technological standard that allows you to authorize one app or service to sign in to another without divulging private information, such as passwords.
OAUTH stands for Open-Authorization, not Authentication. Authentication is a process that verifies your identity, although OAUTH involves identity verification, its main purpose is to grant access to connect you with different apps and services without requiring you to create a new account.
How Does OAUTH Work
OAUTH uses access tokens, and this is what makes OAUTH secure to use. An access token is a piece of data that contains information about the user and the resource the token is intended for. A token will also include specific rules for data sharing.
For example, you want to share your photos from Instagram with Kyrier — An intelligent email platform built for professionals who refuse to let their inbox run their day, but you only want Kyrier to access your profile image. Kyrier does not also need to access your direct messages or friends list. Instagram issues an access token to Kyrier to access the data you approve (your profile image in this case) on your behalf. So an access token will only allow Kyrier to access your profile image, not even other photos on your page. There may be rules governing when Kyrier can use the access token, it might be for a single use or for recurring uses, and it always has an expiration date.
A trip to OAUTH1.0Ville
Welcome to OAuth1.0Ville. Please keep your hands inside the vehicle.
This is where OAuth started. It was built only for websites, back when "an app" meant a web page and nothing else. Although it worked, it had a lot of problems:
- Only three authorization flows (2.0 has six)
- No real plan for mobile or modern apps
- A scaling problem it never solved
It also makes you cryptographically sign every single request, which does not sound like a problem until you are the one debugging why your signature does not match at 2am.
Today almost nobody builds with OAuth1.0. OAuth2.0 is the new standard everyone uses and agrees with.
What is OAUTH2.0
OAuth 2.0 is the version you actually want. Think of it as OAuth 1.0 after it hit the gym, got a haircut, and stopped making your life difficult.
It was a full redesign, not a patch. Several big tech companies threw in feedback, and the goal was simple: completely replace 1.0 and never speak of it again.
Why everyone uses it:
- Works for both apps and websites, not just websites
- Faster and easier to implement
- Actually scales
- Gives you six authorization flows to pick from, so the handshake fits what you are building (server app, mobile app, machine-to-machine, and so on)
Note: You cannot upgrade OAuth 1.0 to 2.0. They are two different things. A site can technically support both, but that is like keeping a landline next to your smartphone.
Examples of OAUTH Technologies
Say you are using Zoho Cliq as a collaboration tool, and you want to know more about the people you work with, both inside and outside your organization. So you enable integration with LinkedIn, so you can learn more about people as you interact with them, without ever leaving Zoho. LinkedIn uses OAUTH to authorize Zoho, so Zoho can pull the LinkedIn profile details you allow, right inside your Zoho workspace, without you handing over your LinkedIn password.
As a developer, you are most certainly familiar with GitHub, or any other Software collaboration and code hosting tools like BitBucket or GitLab. Say you are using GitHub and You wanted to link CodeRabbit with your GitHub account so it can perform automated code reviews once you push or raise a PR, You go to GitHub through the CodeRabbit website and GitHub asks you to download the app, it would then ask you to authorize a connection with the app using your GitHub identity, a process that would be handled using OAUTH. CodeRabbit can then easily access the repositories you enabled it to access and starts listening for any PR or push events, and start reviewing your codes, without you having to sign in to both services every time.
OIDC (Open ID Connect)
OIDC is an authentication strategy to verify a person's identity, it is similar to OAUTH in that, they both give one application access to another application's resources on behalf of the user they are requesting for. Both OIDC and OAUTH have a role to play in enabling two unrelated apps to share information without compromising user data.
Hands-on Implementation with Microsoft Entra ID
Enough of theory. Let us actually create up an app that can read someone's Outlook mailbox using OAuth 2.0. We will use delegated access, meaning the app acts on behalf of a signed-in user, not as itself.
Note: All OAuth2 providers follow the same flow: redirect the user to authorize, get a
codeback, exchange thatcodefor tokens, fetch the user profile, then find or create the user and start a session.Note: Microsoft killed Basic Auth for Exchange Online back in October 2022, and EWS is on life support. In 2026, the only to authorize apps to access data on a users behalf using OAuth 2.0 is through Microsoft Graph, and that is what we will do now.
Step 1: Register your app in Microsoft Entra ID
Go to the Microsoft Entra admin center (portal.azure.com), go to Microsoft Entra ID > App registrations > New registration.
Note: Creating a new app normally is now impossible, you have to join the Microsoft 365 Developer Program
- Give it a recognizable name (this is really important)
- Pick who can use it (single tenant is fine for now)
- Add a Redirect URI. Pick Web if it is a server-side app, or SPA if it is a single-page app. Use something like
https://localhost/myapp/for local testing
Click on register. On the Overview page, copy two things you will need:
- Application (client) ID
- Directory (tenant) ID
Step 2: Get a secret (or better, a certificate)
Go to Certificates & secrets > New client secret. Copy the Value immediately. It is shown exactly once, then it is gone forever and you will be making a new one. Ask me how I know 😂.
Note: certificates are more secure than secrets for production. For a hands-on demo like this, a secret is fine.
Step 3: Add the permissions you need
Go to API permissions > Add a permission > Microsoft Graph > Delegated permissions.
For reading mail, add:
User.ReadMail.Read-
offline_access(this is the one that gets you a refresh token, do not skip it)
Only ask for what you need. The whole point of OAuth is that you do not grab the entire mailbox when you only want to read it.
Step 4: Send the user to log in (authorization request)
Redirect the user to the authorize endpoint. This is the screen where they log in and approve your permissions:
Top comments (0)