#Identity
Articles about Identity — exploring patterns, best practices, and real-world implementations in production systems.
11 posts tagged with identity. ← 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.
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.
Before you can serve a customer in a regulated business, you have to answer a deceptively hard question: are they really who they claim to be? KYC turns that question into an engineering pipeline — collect, verify, screen, risk-assess — and getting it right means balancing legal rigor against an onboarding experience that doesn't drive legitimate customers away.
Before you can serve a customer in a regulated business, you have to answer a deceptively hard question: are they really who they claim to be? KYC turns that into a pipeline — collect, verify, screen, risk-assess — balancing legal rigor against onboarding friction.
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.
When an AI agent spends your money, "the user said so" is not evidence. A signed mandate chain is.
A deep dive on the mandate chain as evidence: verifiable credentials (VCs), signing, the non-repudiable Intent→Cart→Payment chain, revocation and expiry, and why this replaces 'trust me, the user said so' with cryptograp…
When software spends money on your behalf, the merchant has to answer two questions before the charge clears: which agent is this, and what did the human actually let it do.
How a merchant verifies WHICH agent is acting and WHAT it may do.
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.