OAuth means your software never sees the password, and that is the whole point.
A staff member leaves on Friday. On Monday, IT disables her company account. If your software has its own separate login, she can still open it, and somebody has to remember to go in and switch her off.
That is one of the two problems OAuth solves. The other is connecting to a system you do not own, so your application can read a customer’s calendar or files without ever holding their password.
OAuth is an agreement between your software and an account provider such as Google or Microsoft. The person signs in at the provider. The provider then tells your software who they are and what it may do, and hands over a token instead of a password. Revoke the token and the access stops immediately.
Where it earns its place.
The two jobs people confuse
Almost every muddle about OAuth comes from not separating these. They use the same machinery and answer different questions.
- Signing in: proving who this person is, using an account they already have
- Acting on their behalf: reading their Drive folder or writing to their calendar
- Sign-in properly means OpenID Connect, which is a layer on top of OAuth
- Acting on their behalf means scopes, refresh tokens and consent screens
Where we use it
- Staff signing in to a portal with their company Google or Microsoft account
- Customers signing in with Google rather than another password to forget
- Pulling files, calendars or contacts from Google Workspace
- Connecting to a client’s CRM once, then syncing on their behalf
- Letting a partner’s system reach your API without a shared password
The work that is actually involved
The sign-in button takes an afternoon. These take longer and are where the failures live.
- Register the app
- Scopes
- Consent
- Token storage
- Refresh
- Revocation
- Asking for the narrowest permission that does the job
- Storing refresh tokens encrypted, because they are as good as a password
- Handling the day a token is refused and the sync stops silently
- Deciding what happens to a record when its owner leaves the company
- A verification review by the provider where sensitive scopes are requested
The verification step catches teams out. If your application reads Gmail or Drive, Google reviews it before the public may use it, and that has its own schedule.
What OAuth does not do
It answers who this person is. It says nothing about what they are allowed to do inside your software.
- Roles and permissions still have to be built and maintained by you
- A signed-in stranger is still a stranger until somebody approves them
- Group membership from the provider helps, but rarely matches your roles
- Losing access at the provider does not undo what was already exported
We have seen a portal treat any Google account as an employee. Restricting sign-in to your own domain is one line of configuration and it is regularly missed.
When this is the right choice.
- Your staff already have company Google or Microsoft accounts
- Joiners and leavers should be handled once, by IT, not in every system
- Your software must read a customer’s files, mail or calendar
- You would rather not store passwords at all
- A partner or client needs access to your API under their own identity
When it is not.
- Retail customers in India, most of whom will sign in with a phone number and an OTP rather than a Google account
- Machine-to-machine access between two of your own systems, where a managed API key is simpler and easier to rotate
- A single internal application with a handful of users and no company accounts behind it
- Solving who may approve a payment, which is an authorisation question OAuth does not answer
- A team with nobody who can administer the identity provider afterwards
Questions we are asked about it.
Is OAuth the same as single sign-on?
Not quite. Single sign-on is the outcome: one login across several applications. OAuth and OpenID Connect are the common way it is built now, though an older organisation may be using SAML instead, which does the same job differently.
Should our customers sign in with Google?
It depends who they are. For business customers and staff, usually yes. For retail customers in India, a phone number with an OTP fits how people actually sign in, and many will not have a Google account they remember the password to.
What happens when an employee leaves?
If sign-in goes through your company account, disabling that account closes the door everywhere at once. That is the strongest argument for it. Their records inside your system still need a decision about who inherits them.
Can we still have a password login as well?
Yes, and for staff we usually keep one for the administrator account, so a provider outage does not lock everyone out. Every extra way in is also another way in, so it should be deliberate rather than left on by default.
Do we need Google to approve our application?
Only if you ask for sensitive permissions such as reading Gmail or Drive. Plain sign-in, which gives you a name and an email address, does not need a review. We check which side of that line a requirement falls on before quoting.
Can you add OAuth to a system we already run?
Usually, and the sign-in itself is rarely the hard part. The work is matching provider accounts to the users already in your database, and deciding what happens to somebody who has both a password and a company account.
Services that use it.
What it sits with.
Not sure OAuth is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private