Let’s first take a look under the bonnet to understand how the protocols and systems behind this actually work.
OAuth 2.0
OAuth 2.0 is an authorization framework that allows third-party applications to access a user’s resources without sharing the user’s password.
Instead of credentials, the user grants permission and the application receives an access token, which it can use to interact with services through APIs.
This improves security by limiting access and ensuring user credentials are never shared with the third-party application.
OIDC (OpenID Connect)
OpenID Connect (OIDC) is an authentication layer built on top of the OAuth 2.0 authorization framework. Unlike OAuth 2.0, which only handles authorization, OIDC supports both authentication and authorization.
Maintained by the OpenID Foundation, OIDC uses a JSON Web Token (JWT) called an ID token to verify the user’s identity. OpenID Connect relies on a web service to retrieve this JWT, which not only authenticates the user but can also include basic profile information.
OIDC extends OAuth 2.0 by adding an identity layer through the ID token.
For example, if the MyTweets app attempts to access Twitter and the user clicks “Sign in with Twitter,” the app is redirected to the authorization server and requests specific scopes defined in the API, such as the user’s email address. This information is then returned to the requesting application.
Now that we understand the two main elements of this SSO, let’s see how they work together (don’t fall asleep, this is the good part).
How OAuth 2.0 and OIDC Work Together
OAuth 2.0 and OpenID Connect (OIDC) work together to allow users to log in to websites or apps using an existing account, such as Google or Facebook.
OAuth manages authorization, what the application is allowed to access.
OIDC manages authentication — verifying who the user is.
Together they enable features like “Sign in with Google” or “Continue with Facebook.”
When a user selects this login option, the application redirects them to the identity provider (for example, Google). The user authenticates directly with that provider by entering their credentials.
Once the user successfully logs in and approves the request, the identity provider sends the application tokens that confirm the user’s identity and permissions.
In this way, OAuth and OIDC allow users to authenticate securely and grant limited access to their information without sharing their password with the third-party application.
Still confused? here is an example – “Sign in with Google”
Here’s what typically happens when you click Sign in with Google:
- You visit a website and click “Sign in with Google.”
- The website redirects you to Google’s login page.
- Google verifies who you are
(this is the OIDC authentication step). - Google asks whether the website can access certain information, such as your email.
- If you approve, Google sends the application two tokens:
• ID Token (OIDC) – confirms your identity
• Access Token (OAuth) – allows the application to access approved data
- The website verifies the token and creates a login session for you.
From the user’s perspective, it feels seamless.
No new password.
No new account.
Just one click and you’re in!
How easy was that 🙂 , makes everything so simple! (until you read below)
The million-dollar question – So where is the hidden risk?
The password was never shared, so where’s the problem? The answer is simple, the password is no longer the target! the new target are tokens and permissions.
When you click “Allow” on the Google or Facebook consent screen, you’re not giving away your password , but you are granting the application permission to access certain data.
The risk usually isn’t the identity provider (Google, Apple, or Facebook), but the third-party application receiving the token. If that application is malicious or poorly secured, it may misuse the access that was granted. In other words, the target is no longer your password — it’s the tokens and permissions that allow applications to act on your behalf.
The real lesson
“Sign in with Google” isn’t insecure. In many cases, it is actually more secure than traditional password logins. But the security threat has changed. So, instead of protecting passwords, we now need to think about protecting the token, think about which application we are granting access to, what permissions are being granted and how tokens are handled.
In modern authentication systems, the real risk is rarely the login itself. But It’s what happens after you click “Allow.”
So what do we do about this?
To reduce the risks associated with token-based authentication, the focus should be on protecting the token itself. This includes using short-lived access tokens, securing and rotating refresh tokens, enforcing HTTPS to protect tokens in transit, and storing them securely rather than in browser storage. Applications should also validate tokens properly, use secure flows such as PKCE, restrict redirect URIs, and apply the principle of least privilege by limiting scopes. Additional protections such as binding tokens to specific clients and monitoring for suspicious activity help ensure that compromised tokens can be detected and revoked quickly.
I hope you enjoyed that 🙂
Cloud Security blog 