Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to walkthrough of Go microservice authorization puts the entire audience contract on that single argument, and its own deliberately minimal example checks the required scope against the sub claim.
The Engineer · Build desk
Follow any of these and your For You feed starts watching them — no settings page required.
build
The agent asks, the gateway decides: why read-only is not a security boundary1 distinct publisher
build
SSE in Go breaks twice before your handler runs: an illegal header, then a 30-second timeout1 distinct publisher
build
Your meter now runs on someone else's machine: signed receipts, fsync, and failing open1 distinct publisher
build
A Timed-Out Reset SMS Is Not A Failed One, And Your Retry Code Probably Disagrees1 distinct publisher
Compiled by The EngineerSomething wrong?How this is made
The parser hands back one fact: the signature held and the token is live. Every judgement after that belongs to the service alone, because each service that trusts the issuer key decides independently what the claims mean [2].
Start with the standard. RFC 7519 obliges a recipient to identify itself as the intended audience and reject the token when it does not, but only if the `aud` claim is present [6]. A token minted with no `aud` at all sits outside that rule. What rejects it is the second argument to `VerifyAudience`: with `false` an absent audience passes, with `true` it fails [8]. That boolean is doing the work the specification does not, turning "compare the audience when the issuer stated one" into "refuse any token that names no recipient."
Now count the enforcement points, because that is the adoption bill. The incomplete path is a parse, a validity test, and one scope check that reads `claims.Subject` [9]. The corrected validator adds `WithExpirationRequired()`, `WithIssuedAt()`, `VerifyAudience(expectedAudience, true)`, and a scope test [10]. Three guards added, by hand, in every service that terminates a token [15]. Multiply by the number of services and the boundary-contract argument stops being architectural taste.
The scope helper shipped with that validator returns `false` unconditionally and is labelled a placeholder, with a note that scope is typically a space-delimited string in a custom claim [11]. As deny-by-default implementations go, it is hard to improve on.
The claim schema is the more interesting half. Roles describe what a principal is, while scopes describe what a token may do in a specific context, and the post treats conflating the two as the root cause of scope inflation [12]. Its `ServiceClaims` struct embeds `RegisteredClaims` and adds `Roles`, `Scopes`, and a `TenantID` mapped to `tid`, with authorization requiring both a permitting role and a matching scope [13]. The `Authorize` signature, though, takes only claims, action, and resource, so the tenant travels in the token and is not compared anywhere in the path shown [17]. Storing a value in a struct field does not by itself enforce a check on it.
On the invisibility argument, the post asserts that per-service RBAC without a coherent boundary contract produces escalation paths invisible in logs and nearly impossible to audit [14]. The mechanism it describes supports that: a service checking signature, expiry, and scope presence, but never audience, records a valid token and a satisfied permission test, which is an authorized success [16]. What is absent from the log is the comparison that was never made. There is no log excerpt or telemetry showing a measured incidence of missing `aud` checks in the field, so the argument rests on what the code does, without a documented incident behind it.
For it to be your argument too, one condition has to hold: your services must accept the issuer's token directly [2]. If an edge component terminates the issuer token and mints a per-service token carrying a single audience, the audience decision consolidates into the minting service, and the thing you inherit is one place that has to get scope right. If services validate the issuer key themselves, every one of them owns the boolean.
Ranked by verification strength, evidence, and original report placement.
A JWT is a bearer credential with embedded claims; the issuer signs it, and every downstream service that trusts the issuer key must decide independently what the claims mean.
In a monolith the claim-interpretation decision lives in one place; in a microservice mesh it lives in every service, and the coordination mechanism is usually informal: a shared library, a Confluence page, or implicit convention.
Scope inflation occurs when a service reads a broad scope claim as authorization for a specific resource action never intended: a token issued with scope write for a billing API is accepted by an inventory service that checks only for the presence of write, not whether the audience is billing.
Audience misrouting occurs when a token issued for service A is accepted by service B because aud validation is skipped, lenient, or misconfigured.
RFC 7519 requires that if the aud claim is present, the recipient must identify itself as the intended audience and reject the token if it does not.
The post's minimal but incomplete validation path calls jwt.ParseWithClaims, returns ErrUnauthorized on error or invalid token, then calls containsScope(claims.Subject, requiredScope) with the audience check absent; the author says it passes CI and passes code review if reviewers are not looking for audience enforcement, and fails in production when a token issued for the payments service is replayed against the reporting service.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 4, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable code, asserted API
Everything traces to one self-published post, and it splits in two. The listings are verifiable on sight: the minimal example really does pass claims.Subject into its scope check, and the corrected validator really does ship a hasScope that returns false with a placeholder comment. The parts a reader would act on, that golang-jwt leaves aud enforcement opt-in and that the second argument to VerifyAudience is what rejects an aud-less token, are one author's description of a library API with no version cited and nothing alongside it to check against.
Nothing observed
No release, deployment, incident, or usage disclosure appears anywhere in this reporting. The payments-token-replayed-against-reporting case is written as an illustration of what would fail, not as something that did, and a tutorial's own code samples are not evidence that anyone runs them.
Diagnosis outruns the fix
The claim inventory is broad and the working code is narrower. Most Go JWT deployments are said to get everything past signature verification wrong, and the escalation paths are said to be invisible in logs, with neither backed by data. The validator held up against that diagnosis has a scope check that returns false unconditionally and a TenantID field the printed Authorize never reads, so the corrected version as shipped would reject every request rather than sort them.
Attention, not a product
dev.to is a self-publishing platform and this is a developer's own byline rather than a vendor blog, with no product, tier, or proprietary library anywhere in the text; the tooling recommended is the community-standard golang-jwt. What the post competes for is developer attention, which is the most plausible reason its framing is absolute where its code is provisional.
Verifiable only in your own editor
Half of this a reader can settle without leaving their IDE, and the other half our coverage cannot settle at all. One publisher, one author, no second description of golang-jwt's audience semantics, and no version pinned for the library whose API the headline depends on.