Around Go: service security · 3 MIN READ

Authentication and authorization: a verified token is only the beginning

Validate identity separately from permission to act on a particular resource.

A signed token can be genuine and still belong to the wrong audience, issuer or operation. Even a fully valid token does not prove that its subject may read a particular order. Treat authentication as construction of a verified principal and authorization as an explicit resource-scoped decision. Fail closed when either contract is missing rather than accepting whatever identity-shaped value a request provides.

security · A MAP OF THE IDEA

Verify credential
Construct principal
Load scoped resource
Authorize action

Useful when

Validate identity separately from permission to act on a particular resource.
Makes the owner and the failure boundary explicit.

Watch out

Do not trust roles or tenant IDs copied from unverified headers or an unverified token payload.
Run native service and failure tests in your own development environment.

Implementation & operation cost: Additional state and tests must be justified by the demonstrated failure; this lesson is not a requirement for every Go program.

The contract and the failure

Work through the example

With JWT, use a maintained verifier, constrain acceptable algorithms and validate key selection, issuer, audience, expiry and other required claims. Parsing or base64-decoding is not verification. Design key rotation and revocation/session policies. For browser clients, choose cookie/CSRF/CORS rules deliberately; CORS is not an authorization mechanism for non-browser callers.

package main

import "fmt"

type Principal struct{ Subject, Tenant, Role string }
type Document struct{ Tenant, Owner string }

func canRead(p Principal, d Document) bool {
	return p.Subject != "" && p.Tenant == d.Tenant && (p.Subject == d.Owner || p.Role == "auditor")
}
func main() {
	// These are already-verified test principals, not values read from headers.
	d := Document{Tenant: "a", Owner: "user-1"}
	fmt.Println(canRead(Principal{"user-1", "a", "reader"}, d)) // true
	fmt.Println(canRead(Principal{"user-1", "b", "reader"}, d)) // false
}

Read the code

The same subject string in a different tenant is denied. This pure function models authorization after authentication; it deliberately does not parse or verify a JWT. Construct the principal only after the authentication layer validates the chosen credential, and test resource rules independently of token parsing.

Production decisions

Do not trust roles or tenant IDs copied from unverified headers or an unverified token payload. Avoid returning a different secret-laden error body for every verification failure. Test wrong issuer/audience, expired and not-yet-valid credentials, unknown keys, missing required claims and a valid credential attempting another tenant’s resource. These are native service lessons, not registration or accounts added to GopherForge.

Explain it in an interview

A JWT signature is valid. May its subject automatically read any order ID? No. Validate the full credential contract, then check the principal’s permission and tenant scope for this specific resource and action. Describe the state before the operation, its owner, the failure between steps and the evidence you would test. Distinguish what this example demonstrates from the infrastructure a production service still needs.

TAKE THIS WITH YOU

Validate identity separately from permission to act on a particular resource. No. Validate the full credential contract, then check the principal’s permission and tenant scope for this specific resource and action.

Check your understanding

A JWT signature is valid. May its subject automatically read any order ID?

Go to the source

Progress stays in this browser. No account needed.