Skip to content

Standard Reader

Tag

Jwt

Articles and publications tagged Jwt across the Atmosphere.

15articles2publications

Articles

Publications

Sahil Kapoor's PlaybookMay 12, 2026

TTL (Time To Live) is the duration for which a cached value, DNS record, or other transient piece of data remains valid. After the TTL expires, the entry is considered stale and either evicted, refreshed, or revalidated. TTL is one of the simplest knobs in cache design with outsized impact on hit rate and freshness. How it appears in different systems * Caches: per-key TTL on Redis or Memcached entries; sets the lifetime independent of the eviction policy. * HTTP: Cache-Control: max-age=360

Sahil Kapoor's PlaybookMay 12, 2026

An API Gateway is a server that sits in front of a collection of backend services and exposes a single entry point to clients. It typically handles request routing, authentication, rate limiting, request and response transformation, caching, and observability, so individual services can stay focused on business logic. Common responsibilities * Routing: map external paths to internal services * Authentication and authorization: validate JWTs, API keys, or session cookies before the request r

REST APIMicroservices

Sahil Kapoor's PlaybookMay 12, 2026

JSON (JavaScript Object Notation) is a lightweight, text-based data interchange format. It represents data as a small set of structures (objects, arrays, strings, numbers, booleans, null) that map naturally to native types in most programming languages, which is why it has become the default payload format for web APIs. Structure * Object: { "key": value } with string keys * Array: [ value, value, ... ] * String: double-quoted, with backslash escapes * Number: integer or floating-point, n

RFC 8259ECMA-404

Sahil Kapoor's PlaybookMay 12, 2026

Authorization Server

An authorization server is the OAuth 2.0 component that authenticates the resource owner, obtains their consent, and issues access tokens (and optionally refresh tokens and ID tokens) to clients. It is the central identity authority in any OAuth or OIDC system. Core endpoints * /authorize: where the user-agent is sent for login and consent * /token: exchanges authorization codes (or refresh tokens, or client credentials) for access tokens * /userinfo: returns identity claims about the auth

Sahil Kapoor's PlaybookMay 12, 2026

A bearer token is a credential that grants the holder access to a resource simply by presenting the token, with no additional proof of identity. The defining property is that whoever holds the token may use it; there is no cryptographic binding between the token and the requester. How it is used The standard way to present a bearer token is the HTTP Authorization header: Authorization: Bearer . The resource server validates the token (by signature, by lookup, or by introspection) and a

RFC 6750OAuth 2.0

Sahil Kapoor's PlaybookMay 12, 2026

JSON Web Encryption (JWE) is the encryption counterpart to JWS. Where JWS proves integrity and authenticity but leaves the payload readable, JWE encrypts the payload so only the intended recipient can decrypt it. JWE is used when token contents must remain confidential in transit or at rest. How it works A compact JWE token has five Base64URL-encoded sections separated by dots: protected_header.encrypted_key.iv.ciphertext.tag. The header declares the key management algorithm (alg) and the con

Sahil Kapoor's PlaybookMay 12, 2026

JSON Web Signature (JWS) is the cryptographic signing mechanism behind JWT. It defines how to produce and verify a signature over a JSON payload, using either symmetric (HMAC) or asymmetric (RSA, EC, EdDSA) keys. How it works A compact JWS has three Base64URL-encoded sections joined by dots: protected_header.payload.signature. The protected header declares the algorithm (alg) and optionally a key ID (kid). The signature is computed over base64url(header) + "." + base64url(payload) using the d

Sahil Kapoor's PlaybookMay 12, 2026

A refresh token is a long-lived credential issued alongside a short-lived access token, used to obtain new access tokens without prompting the user to authenticate again. Refresh tokens trade convenience for risk: longer life means a wider compromise window, so they are stored more carefully and handled more strictly than access tokens. How it works When the user authorizes a client, the authorization server issues both an access token (valid for minutes) and a refresh token (valid for days t

Sahil Kapoor's PlaybookMay 12, 2026

A session is the server-side state that represents an authenticated user across multiple requests. After a user signs in, the server creates a session record (storing the user ID, expiry, and any auxiliary state) and gives the client a session identifier, typically as an HTTP cookie. Each subsequent request includes the cookie, the server looks up the session, and the request is treated as authenticated. How it works Two designs dominate: * Server-stored sessions. A random opaque ID is stor

Sahil Kapoor's PlaybookMay 12, 2026

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It is the dominant federation protocol in enterprise SSO, where employees authenticate once at a corporate IdP and access many third-party applications. How it works When a user attempts to access an SP, the SP redirects the browser to the IdP with a SAML AuthnRequest. The IdP authenticates the user (using whate

Sahil Kapoor's PlaybookMay 12, 2026

PKCE (Proof Key for Code Exchange), pronounced "pixy", is an extension to the OAuth 2.0 Authorization Code flow that protects against authorization code interception attacks. It was originally designed for native mobile apps but is now the recommended default for all clients, including server-side and single-page applications. How it works The client generates a high-entropy random string called the code verifier and derives a code challenge from it using SHA-256. The client sends the code ch

RFC 7636OAuth 2.0

Sahil Kapoor's PlaybookMay 12, 2026

OIDC (OpenID Connect)

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. Where OAuth defines authorization (who can access what), OIDC defines authentication (who the user is) by adding a standardized ID Token, a defined set of user claims, and a UserInfo endpoint. How it works OIDC reuses the OAuth 2.0 Authorization Code flow with one addition: when the client requests the openid scope, the authorization server returns an ID Token alongside the access token. The ID Token is a signed JWT c

OpenID Connect Core 1.0OAuth 2.0

Clinton's Other Blog

Clinton's Other BlogDec 31, 2025

A Thought on PDS Administration

PDS_ADMIN_PASSWORD needs a lift

atprotomacaroon

nove-b blogDec 22, 2023

Go Langで作成したログイン認証のjwtのアクセストークンが切れた時にどうするか

nove-b blogDec 20, 2023

Go Langで新規登録のWebAPIを作成したので、認証周りをJWTで作成する。

You've reached the end.