Sources

## Problem 1: Complex OAuth standard > “This API also uses OAuth 2.0, and we already did that a few weeks ago. I should be done by tomorrow.” > – Famous last words from the intern OAuth is a very big standard. The OAuth 2.0’s official site currently lists 17 different RFCs (documents defining a standard) that together define how OAuth 2 works. They cover everything from the OAuth framework and Bearer tokens to threat models and private key JWTs. “But,” I hear you say, “surely not all of these RFCs are relevant for a simple third-party-access token authorization with an API?” You’re right. Let’s focus only on the things that are likely to be relevant for the typical API third-party-access use case: - OAuth standard: OAuth 2.0 is the default now, but OAuth 1.0a is still used by some (and 2.1 is around the corner). Once you know which one your API uses, move on to: - Grant type: Do you need … Most teams building public APIs seem to agree as well. Instead of implementing a full OAuth 2.0 subset, they just implement the parts of OAuth they think they need for their API’s use case. This leads to pretty long pages in docs outlining how OAuth works for this particular API. But we have a hard time blaming them; they have only the best intentions in mind for their DX. And if they truly tried to implement the full standard, you’d need to read a small book! … To be fair, many APIs are liberal and provide easy self-service signup flows for developers to register their apps and start using OAuth. But some of the most popular APIs out there require reviews before your app becomes public and can be used by any of their users. Again, to be fair, most review processes are sane and can be completed in a few days. They’re probably a net gain in terms of security and quality for end users. … ## Problem 6: Security is hard As attacks have been uncovered, and the available web technologies have evolved, the OAuth standard has changed as well. If you’re looking to implement the current security best practices, the OAuth working group has a rather lengthy guide for you. And if you’re working with an API that is still using OAuth 1.0a today, you realize that backwards compatibility is a never-ending struggle. Luckily, security is getting better with every iteration, but it often comes at the cost of more work for developers. The upcoming OAuth 2.1 standard will make some current best practices mandatory and includes mandatory PKCE (today only a handful of APIs require this) and additional restrictions for refresh tokens. The biggest change has probably been ushered in with expiring access tokens and the rise of refresh tokens. On the surface, the process seems simple: Whenever an access token expires, refresh it with the refresh token and store the new access token and refresh token.

OAuth 2.0 exists to solve authorization securely, but its complexity creates friction that slows teams and breaks systems. Misconfigured scopes, refresh token mishandling, inconsistent provider implementations — each adds hours to debugging and weeks to delivery. API downtime, broken integrations, and hard-to-reproduce authentication bugs pile up. The protocol’s flexibility is both its weapon and its trap. Each provider — Google, Microsoft, GitHub, custom identity servers — interprets OAuth 2.0 in its own way. The spec leaves room for optional parameters, vendor-specific extensions, and inconsistent error responses. Engineers end up writing special-case code for every provider. Test suites swell with variations that only fail under real-world load. Token management is another recurring pain point. Expiration intervals vary wildly. Some services revoke refresh tokens silently. Others return error messages that tell you nothing useful. Failing to handle the “401 Unauthorized” gracefully can cascade into failed jobs, empty dashboards, and user frustration. Security policies compound the problem. The right mix of scopes, audience claims, and client secrets changes depending on the endpoint and provider. A misstep here doesn’t just break the app — it can expose sensitive data or open attack vectors. There’s no single fix. Minimizing OAuth 2.0 pain points requires tooling that normalizes provider differences, enforces consistent token handling, and logs errors with enough detail to debug in seconds, not days.

### The Documentation Gap Problem The primary challenge developers face isn't understanding what OAuth does, but rather how to actually implement it in production code. Many available resources only scratch the surface, explaining the basic flow without diving into the technical details needed for actual development work. This forces developers to dig deep into RFC specifications and seek help from AI tools to fill in the gaps where traditional documentation falls short. The problem extends beyond just finding information. Even when developers locate implementation guides, they often discover that integrating with existing OAuth providers can be more difficult than building an authorization server from scratch. This counterintuitive situation highlights how the complexity lies not just in the protocol itself, but in the various ways different providers implement it. **Common OAuth Implementation Challenges:** - Documentation gap between concept explanation and practical implementation - Security vulnerabilities including redirect hijacking and account takeover risks - Inconsistent refresh token expiration policies across providers - Complex integration requirements that often exceed library capabilities - Missing standardization for refresh token lifetime communication ### Security Concerns and Design Flaws OAuth2 faces criticism for several structural security issues that can create vulnerabilities in real-world applications. These include account hijacking risks when connecting OAuth providers, redirect vulnerabilities that can leak authorization codes or access tokens, and the optional nature of CSRF protection through state tokens, which many implementations ignore. The front-channel and back-channel distinction in OAuth also causes confusion among developers. While some believe POST requests offer more security than GET requests in HTTPS connections, the reality is that both are encrypted. The real distinction relates to trust boundaries and what information remains private versus public from the client's perspective. **OAuth Security Issues Identified:** - Optional CSRF state tokens frequently ignored in implementations - Redirect vulnerabilities can leak authorization codes via HTTP Referrer headers - Access token leakage possible through URL hash fragments - Account hijacking risks when connecting OAuth providers to existing accounts - Front-channel vs back-channel security misconceptions among developers ### Token Management Challenges Refresh token handling presents another practical hurdle for developers. While refresh tokens theoretically shouldn't expire, many OAuth providers do expire them, requiring applications to refresh periodically to maintain usable tokens. This creates an implementation burden that isn't clearly documented in the specifications. I just wish the spec would have a dedicated refresh_expires_in field in addition to expires_in for refresh tokens, so the client would be better informed about this. The lack of standardization around refresh token lifespans means developers must build applications that can handle varying expiration policies across different OAuth providers, adding complexity to what should be a straightforward process. … ### Conclusion OAuth's implementation challenges stem from a combination of incomplete documentation, varying provider implementations, and inherent protocol complexity that isn't immediately apparent from high-level explanations. While the concept remains sound, developers continue to seek better resources and clearer guidance for practical implementation. The community's ongoing discussions about these challenges suggest that improved documentation and standardization could significantly ease the development burden for future OAuth implementations. Reference: An Illustrated Guide to OAuth

## Common Pitfalls to Avoid OAuth looks neat in diagrams, but most real-world incidents come from implementation mistakes, not the spec itself. The OAuth working group’s security BCP (now RFC 9700) and OWASP’s OAuth cheat sheet both call out the same recurring OAuth pitfalls: wrong flows, weak validation, insecure storage, and overly permissive tokens. … - You may accept tokens that don’t carry the user information or assurances you think they do. - You end up bolting application-level “login” logic onto access tokens that were never designed for that purpose. Use OIDC / ID tokens, or a separate authN system, for “who is this user?”, and keep OAuth 2.0 for APIs focused on “what can this client do on this API?” ### Skipping full token validation in your APIs Another frequent pitfall is only checking that “a token is present” without actually validating it. Both RFC 9700 and OWASP recommend strict, server-side validation for every API call: signature, issuer, audience, expiry, and scope. At a minimum, your resource server should: - Verify the token’s signature against a trusted key set (JWKS). - Check `iss` (issuer), and `aud` (audience) match what your API expects. - Enforce expiry and reject expired tokens, rather than relying on the client. - Confirm required scopes (and any critical claims such as tenant ID). … ### Using the wrong flows Many vulnerable deployments still rely on flows the community now considers unsafe: - Implicit grant – returns tokens in the browser URL fragment; OAuth 2.1 drops it due to token leakage risks. - Resource Owner Password Credentials (password grant) – has the app collect the user’s username/password directly, now formally deprecated and omitted from OAuth 2.1. … ### Over-permissive scopes and long-lived tokens Duende, LoginRadius, and the OAuth security BCP all highlight the same pattern: overly broad scopes and long-lived access tokens are a gift to attackers. Common smells: - Scopes like `full_access`, `root`, `admin_all` are used across multiple APIs. - Access tokens are valid for hours or days, not minutes. A stolen token with `full_access` and a long lifetime is effectively a roaming admin credential. Instead: - Model scopes around capabilities (read/write per domain) and keep them as narrow as possible. - Issue short-lived access tokens and rely on refresh tokens or re-auth for longer sessions. This is one of the most critical levers for reducing the blast radius of token compromise in OAuth 2.0 for APIs. ### Exposing client secrets and storing tokens badly Another recurring set of issues comes from treating secrets and tokens as if they were just another config value. Both OAuth BCPs and multiple security write-ups explicitly warn against: - Shipping client secrets inside SPAs or mobile apps, where they can be extracted from JS bundles or binaries. - Storing access or refresh tokens in `localStorage` insecure cookies or logs that can be accessed via XSS or other means. … ### Flying blind: no monitoring of token usage or failures Finally, a more subtle pitfall: assuming that once you’ve “configured OAuth,” you’re done. In practice, OAuth 2.0 is a high-value target; PortSwigger and others regularly document attacks that exploit weak implementations and misconfigurations rather than the protocol itself. If you don’t monitor how OAuth 2.0 for APIs behaves at runtime, you miss: - Spikes in `401`/`403` errors indicate misconfigured clients or brute-force attacks. - Unusual scope usage (e.g., rarely used admin scopes suddenly getting busy). - Access tokens arriving in query strings instead of headers. An observability layer like Treblle helps close this gap by capturing request/response metadata, status codes, and auth headers, masking sensitive values before they leave your stack. That gives you a safe way to see where flows are failing, which clients are misbehaving, and where scope or lifetime tuning might be needed, without turning your logs into a second credential store. Avoiding these pitfalls doesn’t require inventing new security patterns; it mostly means following the existing OAuth BCPs, OWASP guidance, and treating tokens and flows with the same discipline you already apply to passwords and keys. … ### Validate every token on every request Your APIs should verify the signature, issuer (`iss`), audience (`aud`), expiry, and required scopes for each call, following the OWASP OAuth cheatsheet and RFC 9700 guidance. Never accept bearer tokens in query strings (a behavior OAuth 2.1 explicitly forbids) and never rely on the client to “do the right thing” without server-side checks.

## 6 Common gotchas (and fast fixes) |Oops|Why it happens|Fix| |--|--|--| |**Invalid `redirect_uri`**|Typos, or http vs https.|Copy exact string from dashboard.| |**Missing PKCE**|Old sample code.|Add PKCE always—BCP makes it mandatory.| |**Token too big for cookie**|You stuffed JWT in cookie.|Keep it in memory or split.| |**Refresh token revoked**|User changed password.|Gracefully force re-auth.|

The justification for that statement was the existence of multiple threats, like Insufficient Redirect URI Validation, Credential Leakage via Referrer Headers, Attacks through the Browser History or Access Token Injection and “no viable mechanism to cryptographically bind access tokens issued in the authorization response to a certain client”. To put it in simple words, there are two main threats for *implicit *type: - the leakage of access token transmitted in the URL (also as fragment), - the injection of access token, undetectable by the client. ### Token leakage The leakage threat is covered in RFCs related to OAuth. For example, the open redirect vulnerability was mentioned many times, even in the first OAuth 2.0 RFC [6749]. So basically, … Futhermore, the history shows that bugs in software beyond the reach of OAuth server’s and client’s developers (like the one in Chromium) introduce new vectors for token leakage such as beforementioned leakage via referer header or browser history. That is another motivation to adjust standards to the current situation. … This threat is also related to the fact that **OAuth framework must not be used for authentication**. The OAuth 2.0 RFC stays as follows: Authenticating resource owners to clients is out of scope for this specification. Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience- restricting the access token). … ### Using OAuth 2.0 for authentication is really, really a bad idea… Problems arising from the use of OAuth 2.0 for authentication does not refer only to the *implicit *grant type, but also other types, including *authorization code* type. Lately, I have found an interesting vulnerability in Single Sign-On (SSO) authentication mechanism based on OAuth 2.0. It allowed to log in using accounts from Active Directory. … ## Other good tips and considerations for OAuth During the discussion on Twitter some other threats were mentioned and ideas proposed. The threat worth mentioning, which is actually indepentent form the grant type is the **Cross Site Request Forgery (CSRF)**. If you do not protect your OAuth implementation from CSRF, the attacker can return fake data from API to your users. It is important to **secure OAuth against CSRF attacks with the state parameter**. It should be a pseudo random number generated by the client and verified upon reception of the response from the authorization server, which must reply it unmodified.

All the hard fought compromises on the mailing list, in meetings, in special design committees, and in back channels resulted in a specification that fails to deliver its two main goals – security and interoperability. In fact, one of the compromises was to rename it from a protocol to a framework, and another to add a disclaimer that warns that the specification is unlike to produce interoperable implementations. When compared with OAuth 1.0, the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure. To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation. However, at the hands of most developers – as has been the experience from the past two years – 2.0 is likely to produce insecure implementations. … The resulting specification is a **designed-by-committee** patchwork of compromises that serves mostly the enterprise. To be accurate, it doesn’t actually give the enterprise all of what they asked for directly, but it does provide for practically unlimited extensibility. It is this extensibility and required flexibility that destroyed the protocol. **With very little effort, pretty much anything can be called OAuth 2.0 compliant.** … - **Unbounded tokens** – In 1.0, the client has to present two sets of credentials on each protected resource request, the token credentials and the client credentials. In 2.0, the client credentials are no longer used. This means that tokens are no longer bound to any particular client type or instance. This has introduced limits on the usefulness of access tokens as a form of authentication and increased the likelihood of security issues. - **Bearer tokens** – 2.0 got rid of all signatures and cryptography at the protocol level. Instead it relies solely on TLS. This means that 2.0 tokens are inherently less secure as specified. Any improvement in token security requires additional specifications and as the current proposals demonstrate, the group is solely focused on enterprise use cases. - **Expiring tokens** – 2.0 tokens can expire and must be refreshed. This is the most significant change for client developers from 1.0 as they now need to implement token state management. The reason for token expiration is to accommodate self-encoded tokens – encrypted tokens which can be authenticated by the server without a database look-up. Because such tokens are self-encoded, they cannot be revoked and therefore must be short-lived to reduce their exposure. Whatever is gained from the removal of the signature is lost twice in the introduction of the token state management requirement. … On the other hand, 2.0 defines 4 new registries for extensions, along with additional extension points via URIs. The result is a flood of proposed extensions. But the real issues is that the working group could not define the real security properties of the protocol. This is clearly reflected in the security consideration section which is largely an exercise of hand waving. It is barely useful to security experts as a bullet point of things to pay attention to.

## Common Issues with OAuth 2.0 ### Token Management: A Real Headache One of the biggest issues with OAuth 2.0 is token management. Tokens are what apps use to prove they have permission to access your stuff. But managing these tokens can be a real pain. For starters, tokens expire. That means you have to deal with refreshing them, which can be tricky. You've got to store refresh tokens securely, and that's not always easy. Plus, if a token gets compromised, you've got a security risk on your hands. … ### Security Concerns: The Elephant in the Room Security is always a big deal, and OAuth 2.0 is no exception. There are a few common security issues you need to watch out for. First up, there's the risk of token interception. If someone gets their hands on a token, they can use it to access your stuff. That's why it's so important to use HTTPS to encrypt token transmission. Then there's the issue of token storage. You've got to store tokens securely, but that's easier said than done. Storing tokens in local storage, for example, is a bad idea because it's vulnerable to XSS attacks. Another security concern is the risk of token reuse. If a token is compromised, an attacker can use it to access your stuff. That's why it's important to have a way to revoke tokens and issue new ones. … ### Implementation Challenges: It's Not Always Easy Implementing OAuth 2.0 can be a challenge, especially if you're new to it. There are a lot of moving parts, and it's easy to make mistakes. For one thing, you've got to deal with redirect URIs. These are the URLs that the user is redirected to after they authorize an app. Getting the redirect URIs right is crucial, but it's easy to mess up. Then there's the issue of handling errors. OAuth 2.0 has a lot of error codes, and you've got to handle them all. That can be a lot of work, and it's easy to miss something. Another implementation challenge is dealing with different OAuth 2.0 flows. There are a few different flows, like the authorization code flow and the implicit flow. Each flow has its own use cases and challenges, and you've got to choose the right one for your situation. … ### User Experience: Don't Forget the Users User experience is another big issue with OAuth 2.0. If the user experience is bad, users won't use your app. It's as simple as that. One common issue is the authorization prompt. This is the screen that asks the user to authorize an app. If the prompt is confusing or scary, users won't authorize the app. Another user experience issue is the redirect flow. If the redirect flow is slow or confusing, users will get frustrated and give up. Then there's the issue of token expiration. If a token expires and the user has to re-authorize the app, that's a bad user experience. You've got to handle token expiration gracefully to avoid this. Also, you've got to think about the user experience of revoking access. If a user wants to revoke access to an app, it should be easy to do. If it's not, that's a bad user experience. … Then there's the case of the confusing authorization prompt. A few years ago, a popular photo-sharing site changed its authorization prompt. The new prompt was confusing, and a lot of users thought they were being phished. The site had to revert to the old prompt to avoid losing users. Another example is the case of the slow redirect flow. A few years ago, a popular music streaming service had a slow redirect flow. Users would authorize the app and then have to wait for a long time to be redirected back to the app. A lot of users got frustrated and gave up.

### Token leakage The leakage threat is covered in RFCs related to OAuth. For example, the open redirect vulnerability was mentioned many times, even in the first OAuth 2.0 RFC [6749]. So basically, **when you follow the standard, you significantly reduce the risk**. Of course, the truth is that if something is prohibited in the standard it does not mean it will not happen and we should strive to create recommendations as secure as possible, minimizing the risk. Actually, that was the motivation of the published draft. On the other hand, if you do not follow the standard properly, you are always at higher risk. Futhermore, the history shows that bugs in software beyond the reach of OAuth server’s and client’s developers (like the one in Chromium) introduce new vectors for token leakage such as beforementioned leakage via referer header or browser history. That is another motivation to adjust standards to the current situation. … This threat is also related to the fact that **OAuth framework must not be used for authentication**. The OAuth 2.0 RFC stays as follows: > Authenticating resource owners to clients is out of scope for this specification. Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience- restricting the access token). … ### Using OAuth 2.0 for authentication is really, really a bad idea… Problems arising from the use of OAuth 2.0 for authentication does not refer only to the *implicit * grant type, but also other types, including *authorization code* type. Lately, I have found an interesting vulnerability in Single Sign-On (SSO) authentication mechanism based on OAuth 2.0. It allowed to log in using accounts from Active Directory. … The clients that accepted Google account either verified whether the logged in e-mail address is accepted (there was a list of accepted Google e-mail addresses) or simply allowed anyone (any Google e-mail address) to have a valid account. Unfortunately, the other group of clients were not aware of the fact that users can log in to SSO also with Google accounts and additionaly, they did not verify whether the authorization *code*, that was returned to them with redirection, came from the login process initiated by them. They just used the *code* to get the access token.

**Bad:** When requesting an Access Token the request will fail if you include any parameters that it is not expecting. Google does not require a `state` or `type` parameter when getting the token like some other APIs do and will give you a 400 Bad Request with an `invalid_request` error if they are included. … ### 37signals **Bad:** When you create the app you select which services you want your app to have access to but during the auth flow only one of the services is displayed. **Bad:** There’s no support for limiting access to read-only via scopes. The only option is full read/write for all of the apps selected. … ### Box **Bad:** The redirect URL settings requires HTTPS which can be difficult if you’re trying to test locally (for instance my test app runs on http://localhost:5001 which is accepted every where else). Box has informed me this will be resolved soon. **Bad:** Does not use scopes for read-only or read/write access (is configured with the application). Box has also told me they will be changing this once they have more than one scope.

Over the years, attackers have found ways to exploit misconfigured flows, steal tokens, and impersonate users. These vulnerabilities—and the inconsistent way OAuth 2.0 has been implemented—are a key reason why OAuth 2.1 was introduced: to streamline best practices and close common security gaps. **Read more:** OAuth Vulnerabilities and Misconfigurations (and How to Fix Them) ... OAuth 2.0 has been extended and adapted through community-driven best practices, optional security add-ons, and third-party library conventions. While flexible, this patchwork approach often led to inconsistent implementations and avoidable vulnerabilities. OAuth 2.1 was introduced to improve security and simplicity across the ecosystem. Rather than reinventing the protocol, OAuth 2.1 streamlines it, retaining only the most secure, widely adopted practices while removing outdated and risky features like the implicit and password grant types. It formalizes what secure OAuth should look like in 2025 and beyond. … ### Exact redirect URI matching OAuth 2.0 allowed flexible redirect URI matching using wildcards and substring patterns—intended to make development smoother. Unfortunately, this flexibility opened the door to **open redirect vulnerabilities**, where attackers could manipulate redirect URIs to steal tokens or impersonate apps. OAuth 2.1 requires **exact string matching** for redirect URIs. Clients must pre-register every allowed redirect URI, and the authorization server must enforce an exact match. This eliminates ambiguity and makes unauthorized redirects far harder to exploit.

Security issues in OAuth 2.0 rarely stem from problems in the specification itself. Instead, they arise from how individual applications interpret or configure OAuth in real-world environments. This article highlights seven common security pitfalls that appear frequently in real-world systems — issues that weaken defenses, undermine trust boundaries, or introduce subtle vulnerabilities that attackers can exploit. … ## 1. Choosing the Wrong Grant Type for the Scenario OAuth 2.0 offers several grant types, each intended for a specific kind of client and deployment environment. A common source of problems is using these flows without considering whether the client is public or confidential — that is, whether it can securely store secrets. A common example is using the Client Credentials grant (`client_credentials`) for user authentication. Because this flow has no end user, it is only appropriate for machine-to-machine communication. Applying it to a login flow blurs the line between a user and an application and leaves the system with no cryptographic proof of who is actually present. … ## 3. Redirect URI Pitfalls A redirect URI is the callback URL an application registers with the authorization server — for example, `https://app.example.com/auth/callback`. Problems arise when these URIs are either too permissive or incorrectly configured. *Overly permissive redirect URIs* may be accepted by some providers but are insecure in practice, especially when they include wildcards, broad domain patterns, or allow both HTTP and HTTPS — giving potential attackers more flexibility to redirect authorization codes to malicious endpoints. *Misconfigured redirect URIs*, on the other hand, may be valid or invalid and can break the flow or open the door to unintended redirection behavior. Examples include mismatched callback paths (even small differences such as a single forward slash matter), typos in the URL, and unused registered redirect URIs. Redirect URIs should be treated as strict allow-lists, matching exactly what the authorization server expects. As has been pointed out, even small inconsistencies can undermine OAuth's protections and create opportunities for token interception. ## 4. Incomplete or Incorrect Token Validation in APIs Once an access token reaches an API, proper validation is essential. APIs are responsible for verifying several core properties of every token, and security weaknesses emerge when these checks are skipped or implemented incorrectly. In ASP.NET Core, much of this validation is enabled by default, but it can still be misconfigured or overridden inadvertently. At a minimum, APIs should validate: - **Issuer (`iss`)**: ensuring the token was issued by the expected authorization server - **Audience (`aud`)**: confirming the token was intended for this API - **Expiration (`exp`)**: rejecting tokens that are expired or outside their valid window - **Signature**: verifying that the token has not been tampered with OAuth token validation may include additional checks depending on the system's architecture and requirements, but these core fields form the minimum required for an API to enforce its trust boundary. When APIs omit or weaken these checks, they may inadvertently accept tokens from the wrong tenant, tokens issued for different services, or tokens that are expired or replayed. … ## 5. Storing Tokens Insecurely on the Client Even when OAuth flows are configured correctly, applications can weaken security by storing tokens in an unsafe manner. In browser-based applications, placing tokens in `localStorage` or `sessionStorage` exposes them to any script running on the page, including malicious scripts injected through Cross-Site Scripting (XSS) attacks. A script with access to the page can read the tokens and send them to a potential attacker. … ## 6. Overly Broad Scopes and Excessive Permissions OAuth scopes determine which resources a client is allowed to access, but they are easy to misuse. A common pitfall is treating scopes as if they are roles or broad access tiers instead of precise, task-specific permissions. When scopes are defined too broadly — or when clients request more access than necessary — the system begins to violate the principle of least privilege. Overly broad scopes increase the impact of token leakage — situations where an access token is exposed to an unauthorized party. If a leaked token grants wide-ranging permissions, an attacker may be able to call multiple APIs, read or modify high-value data, or perform privileged operations. This risk grows in distributed systems, where a single access token can unlock several downstream services. A more secure pattern is to keep scopes narrowly defined and to grant only the minimum access required for each scenario. In practice, this means: - Designing small, task-specific scopes - Requiring clients to request only the permissions needed for the operation they are performing - Reviewing scope definitions periodically as APIs and access patterns evolve … ## 7. Using Long-Lived Access Tokens Long-lived access tokens are widely discouraged in the OAuth ecosystem. The longer an access token remains valid, the greater the opportunity for an attacker to steal and reuse it. Most access tokens are self-contained, so APIs will treat them as valid for their entire lifetime.