#Authentication
Articles about Authentication — exploring patterns, best practices, and real-world implementations in production systems.
11 posts tagged with authentication. ← All posts
Identity is the front door to everything, which makes it the most attacked part of most systems and the place where a single mistake compromises everyone. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and doing yourself what a library should do. This closing post is the practical security checklist.
Identity is the front door to everything, which makes it the most attacked part of most systems. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and rolling your own.
Logging a user in is the easy part; keeping them logged in — and, harder than anyone expects, logging them out — is where identity gets subtle. Sessions bridge stateless requests into a continuous identity, single sign-on shares that identity across apps, and single logout is a genuinely hard problem that most systems get partly wrong.
Logging a user in is the easy part; keeping them logged in — and, harder than anyone expects, logging them out — is where identity gets subtle. Single logout is a genuinely hard problem that most systems get partly wrong.
SAML is older, XML-heavy, and unfashionable — and it still runs enterprise identity, because the corporate world standardized on it a decade before OIDC existed and enterprise software moves slowly. If you build anything sold to businesses, you will meet SAML, and understanding it as "the same federated-login idea as OIDC, different machinery" is what makes it approachable.
SAML is older, XML-heavy, and unfashionable — and it still runs enterprise identity. If you build anything sold to businesses you will meet SAML, and understanding it as 'the same federated-login idea as OIDC, different machinery' makes it approachable.
Everyone kept using OAuth to log users in, and everyone kept doing it slightly wrong, because OAuth was never designed to answer "who is this user?" OpenID Connect is the fix: a thin, standardized authentication layer on top of OAuth that adds one crucial thing — an ID token that securely tells you who the user is. It's what "Sign in with Google" actually runs on.
Everyone kept using OAuth to log users in, and kept doing it slightly wrong, because OAuth was never designed to answer 'who is this user?' OpenID Connect is the fix: a thin authentication layer on OAuth that adds an ID token. It's what 'Sign in with…' runs on.
When agents from different organizations delegate real work to each other, trust cannot be assumed, so A2A builds authentication into the Agent Card and demands it on every request.
When agents from different organizations delegate real work, trust cannot be assumed, so A2A builds authentication into the Agent Card and demands it on every request.
Tokens are the currency of modern identity — they carry proof of authorization and identity across every request. But "token" hides real distinctions: access versus refresh versus ID tokens do different jobs, and a JWT you can read but must validate correctly is a razor that cuts both ways. Most identity vulnerabilities live in how tokens are issued, stored, and checked.
Tokens are the currency of modern identity — access, refresh, and ID tokens do different jobs, and a JWT you can read but must validate correctly is a razor that cuts both ways. Most identity vulnerabilities live in how tokens are issued, stored, and checked.
OAuth isn't one procedure — it's a family of flows for different kinds of clients, and picking the wrong one is a security bug, not a style choice. The good news is that modern guidance has collapsed the confusion: for almost every case today, the answer is the authorization code flow with PKCE, and knowing why the alternatives were deprecated is knowing OAuth security.
OAuth isn't one procedure — it's a family of flows for different clients, and picking the wrong one is a security bug. Modern guidance collapsed the confusion: for almost every case, the answer is the authorization code flow with PKCE.
OAuth solved a specific, once-terrible problem: how does an app access your data on another service without you handing over your password? Its answer — a scoped, revocable token granted through a trusted intermediary — is elegant, but only if you remember what OAuth actually is. It's authorization, not login, and everything about it makes sense once you hold that firmly.
OAuth solved a once-terrible problem: how does an app access your data on another service without your password? Its answer — a scoped, revocable token through a trusted intermediary — is elegant, but only if you remember it's authorization, not login.
Half of all identity confusion — and a surprising share of security bugs — comes from blurring two words that sound alike and mean opposite things. Authentication asks "who are you?"; authorization asks "what are you allowed to do?" Every protocol in this series exists to answer one or the other, and mixing them up is how you build systems that are both insecure and broken.
Half of all identity confusion — and a surprising share of security bugs — comes from blurring two words: authentication asks 'who are you?', authorization asks 'what are you allowed to do?' Every protocol in this series answers one or the other.
"Just hash the password" is advice that's simultaneously right and dangerous — right that you never store plaintext, dangerous because a fast cryptographic hash like SHA-256 is exactly the wrong tool for passwords. Hashing, message authentication, and password storage are three different jobs that all involve hashing, and confusing them is a classic source of real breaches.
'Just hash the password' is simultaneously right and dangerous — right that you never store plaintext, dangerous because a fast hash like SHA-256 is the wrong tool for passwords. Hashing, MACs, and password storage are three different jobs that all involve hashing.
The second post in the API Security series — a practical tour of API keys, session cookies, bearer tokens, OAuth 2.0, OIDC and JWTs, plus how to verify a token correctly and where authentication quietly breaks.
Proving who is calling: API keys vs sessions vs bearer tokens, OAuth 2.0 grant types and OIDC, and JWT validation done right — the alg:none / algorithm-confusion pitfalls, verifying signature/exp/aud/iss, and access vs refresh token rotation.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.