<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Oauth2 on Blog Notes</title><link>https://blog.vitalvas.com/tags/oauth2/</link><description>Recent content in Oauth2 on Blog Notes</description><generator>Hugo</generator><language>en_US</language><lastBuildDate>Tue, 23 Jun 2026 14:27:15 -0400</lastBuildDate><atom:link href="https://blog.vitalvas.com/tags/oauth2/index.xml" rel="self" type="application/rss+xml"/><item><title>JWT vs Opaque Access Tokens</title><link>https://blog.vitalvas.com/post/2026/06/23/jwt-vs-opaque-access-tokens/</link><pubDate>Tue, 23 Jun 2026 14:27:15 -0400</pubDate><guid>https://blog.vitalvas.com/post/2026/06/23/jwt-vs-opaque-access-tokens/</guid><description>&lt;p&gt;When you issue access tokens for an API, you face an early architectural decision: should the token carry its own meaning, or should it just be a reference?
A JWT (JSON Web Token) is self-contained, it packs claims and a signature into the string itself.
An opaque token is a random, meaningless identifier that points to state stored on the server.
Both are valid OAuth 2.0 access token formats, and the choice shapes how validation, revocation, and scaling work for the rest of the system.
This article compares the two approaches and the trade-offs that should drive the decision.&lt;/p&gt;</description></item></channel></rss>