Great question—this is something a lot of developers grapple with when first implementing OAuth2 token flows. Let’s break down the key drawbacks of skipping access token checks and using refresh tokens for every request:

• Wasted API Overhead & Latency
  Every time you call the token endpoint to fetch a new access token, you’re adding an extra network round trip. If your access token is still valid (which it will be most of the time, since they’re short-lived but not that short), this is completely unnecessary. It increases load on the authorization server and makes your app’s response times slower—small delays add up for users, especially on spotty networks.

• Elevated Security Risks
  Refresh tokens are long-lived credentials, far more valuable to an attacker than a soon-to-expire access token. By sending your refresh token with every request, you’re raising the odds of it being intercepted (e.g., via man-in-the-middle attacks, or accidental logging). Many providers also use refresh token rotation: each time you use a refresh token, it gets invalidated and replaced with a new one. Overusing it could lead to losing your valid refresh token due to a failed network request, leaving your user logged out unexpectedly.

• Poor User Experience
  Even minor delays from extra API calls can make your app feel sluggish. Users expect snappy interactions, and unnecessary refresh token calls can introduce noticeable lag, especially if your app makes frequent resource requests.

• Misaligns with OAuth2’s Core Design
  The OAuth2 spec intentionally separates short-lived access tokens (for frequent resource access) and long-lived refresh tokens (for renewing access without re-authenticating users). This layered approach balances security (limiting exposure of sensitive credentials) and performance (fast access to resources when possible). Bypassing this design undermines the system’s intended safety and efficiency.

A Smarter Middle Ground #

Most apps use a balanced approach instead of choosing one extreme:

1. If your access token is a JWT, parse its exp (expiration) claim locally to check if it’s still valid or nearing expiration.
2. If it’s valid, use it directly for the resource request.
3. If it’s expired (or you get a 401 Unauthorized response indicating token invalidity), then use the refresh token to fetch a new access token.

This minimizes unnecessary requests, reduces security risks, and keeps your app responsive.

内容的提问来源于stack exchange，提问作者plsnoban