Best Practices for Access, ID, and Refresh Tokens

-

 When building modern applications with OAuth 2.0 and OpenID Connect, developers often get confused about where to store tokens. This decision is crucial because storing them incorrectly can open doors to serious vulnerabilities like XSS or CSRF attacks. Let’s break it down.

Understanding the Tokens

  • Access Token → Proves what you can do. It authorizes the client to call APIs on behalf of the user.

  • ID Token → Proves who you are. It carries identity information (name, email, roles) about the authenticated user.

  • Refresh Token (optional) → Used to obtain new access tokens without making the user log in again.

Each token has a different lifespan and security sensitivity, so the storage strategy must match the risk.

Storage on the User Side (Frontend)

1. Web Applications

  • Best practice: Keep tokens in memory (JavaScript variables).

  • Safer persistence: Use HTTP-only, Secure cookies if tokens must survive page reloads.

  • Avoid: localStorage and sessionStorage for tokens. They’re vulnerable to cross-site scripting (XSS).

2. Mobile Applications

  • Use platform-provided secure storage:

    • iOS → Keychain

    • Android → Encrypted Shared Preferences or Keystore

This ensures tokens are protected even if the device is compromised at the application level.

Storage on the Backend (Server/API)

Access Tokens

  • Typically not stored long-term.

  • The server simply validates the token on each request (signature, issuer, audience, and expiry).

  • Some apps keep metadata (like userId → lastAccessToken) in a database or cache (e.g., Redis), but this is optional.

ID Tokens

  • Often used only during the login process.

  • The backend can extract user claims (email, roles, permissions) and store them in a session or database instead of keeping the raw token.

Refresh Tokens

  • Must be stored securely because they live longer.

  • Store in an encrypted database or secure cache.

  • On the client, prefer HTTP-only Secure cookies.

Putting It All Together

  • Frontend → Short-lived storage in memory or secure cookies.

  • Backend → Validate tokens per request; securely store refresh tokens if required.

  • Rule of thumb: Never expose long-lived tokens (like refresh tokens) to JavaScript or client-side storage.


Comments

Post a Comment

Popular posts from this blog

REST vs RPC vs GraphQL: Choosing the Right API Style

-
 APIs are the glue that connects modern applications. Whether you’re building a public-facing service or a complex microservices ecosystem, the design style of your API plays a huge role in performance, usability, and maintainability. Three common approaches dominate today’s landscape: REST , RPC , and GraphQL . Each comes from a different philosophy, and each has strengths and trade-offs. Let’s compare them. 1. REST (Representational State Transfer) REST treats everything as a resource and interacts with those resources using standard HTTP methods. It’s resource-oriented and built on the web’s existing semantics. Example : GET / users / 123 → fetch user 123 PUT / users / 123 → update user 123 GET / users / 123 / orders → fetch orders for user 123 ✅ Pros Standardized and predictable Widely supported by tools and libraries Leverages HTTP features (caching, status codes, headers) Great for resource-centric systems ❌ Cons ...
Read more

Fibonacci Agile Estimation

-
Image
  Most agile teams opt to combine the Fibonacci sequence with an estimation method called   planning poker . In Planning Poker, each team member has a modified deck of cards that corresponds with the Fibonacci sequence. When a task is up for estimation, each member individually picks a card that best matches their estimate for that item. Everyone then reveals their cards simultaneously and discusses their estimates until they reach a consensus. Why is the Fibonacci sequence used in agile estimation? The point of Fibonacci is to force your hand when estimating larger, complex tasks instead of wasting time nitpicking over minor differences . This is best explained through an example that compares simple time-based estimation with Fibonacci estimation. Let’s say you estimated your stories on a steady scale of 1-50.  When you discuss your backlog item with the team, one picks 31, the other 36, and a third 38. When the gap between each estimate is a single integer it’s hard to...
Read more

How to Add LICENSE.txt to Your .NET Project Using Azure Pipelines

-
Image
   Including a license file in your NuGet package is a best practice that improves transparency and compliance for your open-source or internal packages. If you store your   LICENSE.txt   securely in Azure DevOps, you can automate its inclusion into your .NET project using Azure Pipelines. In this guide, I’ll walk you through how to: Download the LICENSE.txt from Azure DevOps secure files Copy the file into your project directory Modify the .csproj file dynamically to include the license file during build and packaging 🔐 Step 1: Download  LICENSE.txt  from Secure Files First, upload your  LICENSE.txt  to the  Secure Files  library in Azure DevOps. Then, in your YAML pipeline, use the  DownloadSecureFile  task to fetch it at runtime. - task: DownloadSecureFile@1 displayName: 'Download LICENSE.txt' inputs: secureFile: 'LICENSE.txt' This will download the file to a temporary location on the build agent ( $(Agent.Te...
Read more