Written by James Aldridge

OAuth 2.0 resource tokens are secure digital code keys. They are used by applications, that cannot have access to your password, to access portions of your private information. More specifically, they are:

“A temporary digital key to allow non-human entities granular and unsupervised access to private information held in another secure system.”

The resource tokens are generated by an authorisation server and are stored by applications, for repeated uses.

Why does OAuth 2.0 exist?

Around 2012, applications found they needed to gather and exchange user’s information with each other to function. Letting these apps have access to user’s passwords was clunky and not secure; we now refer to this method as “legacy authentication”. Early multifactor authentication (MFA) then made legacy authentication impossible, as the applications could not navigate around it.

OAuth 2.0 was the solution to this problem.

The Non-Technical Explanation for OAuth 2.0

If you have ever been prompted to “Sign in with Facebook”, used SSO, or allowed an app to access to your Google photo library, you have interacted with OAuth 2.0.

The most useful analogy is that OAuth 2.0 tokens are digital assets that work in the same fashion as hotel room keycards. These keycards are programmed to open only specific doors in a hotel – they are not a skeleton keys to the whole building. Keycards are time-limited – if retained, they could not be used to open those same doors a year from now. And the keycards will work for anyone that holds them – the identity of the user is not relevant.

What are their strengths?

OAuth 2.0 resource tokens allow for increased functionality between applications, while also allowing for tailored security controls to maintain the least level of access. The tokens can be tailored with lifetimes and specific information access rights, and can be provisioned and revoked without resetting the user’s password.

The information contained within the tokens is never known by users, so they are phishing-resistant, do not contribute to password fatigue, and have a reduced risk of credential theft.

What are their weaknesses? 

OAuth tokens are not an identity solution, and should not be used as one. The tokens guarantee access to an information resource regardless of who presents them.

OAuth tokens are designed to bypass MFA, are unaffected by password resets, and their simple nature and lack of a linked identity makes reviewing access logs difficult (this is a feature, not a flaw). This makes “defence in depth” and incident triage more difficult.

The tokens are only as secure as the human that tailored them. If a token is provisioned an over-wide scope and an infinite lifetime, it could be used as a permanent backdoor. A user could also be tricked into granting a legitimate OAuth token to a malicious application.

OAuth tokens are confidential digital assets and can be exposed at rest or in transit by someone attacking the system that contains them. This is referred to as being “stolen”, but a better term would be “duplicated”, as the original token is not modified. A duplicated token can be used-at will by an attacker until it is revoked.

OAuth Visualisation

If you would like to learn more about the technical aspects of OAuth tokens, this 2018 talk by Okta is an excellent resource that has stood the test of time.

What’s the state of OAuth 2.0 in 2026?

Despite its flaws, OAuth 2.0 has been widely adopted into almost every digital service we use today. The protocol has also had optional upgrades, such as the Authentication solution OpenID Connect and the banking industries Financial-Grade API.

Today, OAuth 2.0 has come to the end of its useful life and is currently being upgraded to OAuth 2.1 – which contains a decade of hard-won security experience. 2.1 is a significant upgrade and includes:

• Many of the “optional” security packages of OAuth 2.0 are now mandatory
• Compatibility features with Legacy Authentication and insecure browsers have been removed
• Mandatory rotation of single-use refresh tokens
• Optional cryptographically bound resource tokens as an identity layer
• Functionality to grant tailored information access to agentic AI.

This is the good news. The bad news is that:

• Legacy systems may be incompatible with OAuth 2.1
• There are 14 years of exploitable OAuth 2.0 technical and security debt that will have a long tail
• Modern AI is able to automate OAuth 2.0 exploitation attacks to a scale and pace not previously seen – both technical and social engineering.

Auth0, Okta, Google, and Microsoft are already moving to deprecate OAuth 2.0 and encourage migration to OAuth2.1.

Where can we go from here

• We would recommend that organisations who have not done so to map their OAuth landscape. This mapping is critical, as it’s impossible to secure information systems that you don’t know you have.
• It would be prudent to identify if key dependencies in an organisation’s supply chain are mandating OAuth 2.1 implementation, and the timescales it would need to be achieved by.

Despite their drawbacks, OAuth tokens remain a useful security tool for enforcing least privilege. As an information system is ultimately only as secure as the information that it has access to, OAuth 2.0 and 2.1 can prevent the permission sprawl that contributes to confidentiality breaches.

References and Further Reading:

OAuth 2.0 and OpenID Connect (in plain English)

OAuth 2.1 Is Here: What Changed, What’s Deprecated, and How to Migrate Your App – DEV Community

EvilTokens and OAuth Abuse: How Device Code Phishing Bypasses MFA

Inside an AI‑enabled device code phishing campaign | Microsoft Security Blog

https://www.obsidiansecurity.com/blog/the-new-attack-surface-oauth-token-abuse