#39 Tokens — The Complete Story

Let me make you a promise, by the end of this episode no one will be able to casually brush off the word tokens in front of you ever again. I need to set this stage here because I've already made some big claims. It's another day in the office, you know, a usual large conference room. The kind with this screen that sometimes doesn't connect to your laptop and there is a phone in the middle that sometimes doesn't unmute or the camera controls doesn't work. Right. It's a very usual turn of the mill conference room and there are maybe 12 people in the room, your architects, engineers, a couple of product managers, one person from the legal who got added to the invite by mistake and is quietly hoping no one notices. And at the front of the room, there is a vendor or two people actually, sharp slides, confident voices and good suits. Now scratch that. Great suits. They are pitching an AI security platform and you know the type, unified identity, fabric, zero trust native, agent AI ready. The kind of pitch where every third slide has an architecture diagram that looks like someone exploded a bowl of spaghetti and called it modern. We're talking about tokens a lot, jot this, beer a token that an our platform issues short lived tokens with cryptographic binding. We leverage OAuth 2.0 flows with pixie and deep off for enhanced security. The room is nodding, heads moving up and down in that particular rhythm. That means I don't want to be the one who asks a question. And then someone asks a question because they are one of the junior architects. But this junior architect, she is very smart, she's maybe three years into her career. Very bright. And she raises her hand and says quietly but clearly what exactly does this token let someone do and if it leaks how long does an attacker have before it stops working. So hello and welcome to another episode of the identity navigator and this is your host Rohit. So having made such a big claim, I need to live up to it. So let me get back to the story and the stage was set, a question was asked and then there was this silence and let's get back to that awkward silence. Now it was not the good kind of silence, the kind where you can hear the air conditioning. This was the kind of silence it was. The vendor looked at this slide and then at their colleague, then back at the room. Now there is part people. So they say great question. It's fully configurable. Our platform gives you complete control over token lifetime and then they move on to the next slide, nobody followed up, nobody asked what fully configurable meant and in practice nobody asked what the default lifetime was. Nobody asked what happened to existing tokens when you discovered a breach they kept nodding because they didn't want it to be called out. And I'm not here to judge anyone because I've been that room, I've been one of the nodding heads and for a long time tokens were one of those things where if you half understood them, you could get through most meetings without anyone noticing. The vocabulary is large enough and the specifications are dry enough that tokens become a kind of currency. You could spend without anybody checking your wallet, but that ends today. By the end of this episode, you are not going to be in that room anymore or you're going to be in that room, but you're just not going to nod along anymore, you get the point, right? So you are going to be the person who can ask this sharp questions and understand the answers. You're going to know what a token actually is, how the major types differ, how OAuth uses them and why our token never expires is either a lie or a catastrophe depending on the day and how to interrogate any token story that lands in front of you. It could be from a vendor, from an internal team, from an architecture diagram, somebody drew at 11 p.m. the night before the review or five minutes before the meeting using chat and GPT because at the end of the day, tokens are in magic, they are not mysterious and they are permission slips, very specific, very powerful permission slips that are entire digital ecosystem or infrastructure runs on and once you understand them, like really understand them, a whole category of security nonsense stops working on you. So what is a token really? Let's start with the thing itself, what actually is a token? Now here is a definition, I want you to carry with you. A token is a digitally signed, time boxed permission slip, that's it, that's the whole thing. Now you know what tokens are, but let me break that down because each word is doing real work, so what did we say, digitally signed, time boxed permission slips, digitally signs means that someone, specifically someone whose identity and authority you trust has put their cryptographic signature on this thing, like a wax seal on a letter except its math and you can't fake it. Boxed means it has an expiration, it is by design, a temporary thing. And permission slip means it authorizes something specific, not everything, something. It says what you are allowed to do in what system on what behalf. And now the definition should make sense to you, a token is a digitally signed, time boxed permission slip, that's it. Now contrast that with the password, a password is a secret that proves who you are, you know the secret, therefore you are you, simple, direct and binary, you are either authenticated or you are not, a token is different, a token says this entity at this time is allowed to do this specific thing, in this specific place for this long. Think about what that distinction means, a password is identity, a token is capability, and capability is a much more precise thing to reason about than identity, because you can scope it, limit it, time bound it and revoke it without affecting the underlying identity at all. So let's use three analogies that we all must have come across in some way shape or form. Or maybe let's use two analogies, analogy one, I'm pretty sure you would have heard it is the hotel key card, when you check into a hotel, you don't get a key to the hotel, you get a key to room 412, it works on room 412, maybe the gym, maybe the pool, it doesn't work on room 413, it doesn't work on the employee area and it stops working 11 a.m. on the checkout day, the front desk issued it, it has scope and it has a lifetime, and if you lose it, whoever finds it can get into room 412 until checkout, that's the problem, but it's a bounded problem, it's not someone has your entire identity, analogy two, and you might have heard about this one or maybe the bouncer one or maybe both of them, but I'll go with the concert analogy, so you go to a festival, you get a wristband, it says you're allowed to be in general admission, not backstage, not the VIP lounge, general admission. If you try to go backstage, security stops you, the wristband is your token, it was issued by the venue, it has a clear scope, and when the festival is over, it's worthless. If you lose it and someone else picks it up, they get into general admission, which is bad, but it's not the same as someone stealing your driver's license, so a software is any of these things translated to software, sorry a token is any of these things translated to software flying over SVTP, and here is the thing about these analogies, all of them have the same failure mode, if someone takes your wristband, your key card, they get the access is represents, possession is enough and we will solve this possession problem as well, but this property called BRR model is exactly how most software tokens work, and it is at the heart of why token security matters. Now one more thing before we move on. When people sit token in a security conversation, they might mean any of the dozen different things or dozen different things like hardware tokens, one time password session cookies, API keys, jobs, opaque strings and whatnot. But we are here to cover what exactly or actually matters in modern systems. But I want to note that the word itself is doing heavy lifting across a lot of contexts part of the problem we are solving today is exactly that people use tokens as though it has one meaning and it doesn't being precise about which kind of token you are talking about is half the battle. So we have to understand how we got here to understand where we are going and I know I sound old when I say this but it really helps trust me on that. Okay, so the word at that time was bad specifically it was bad and very specific and now almost unthinkable. In the early days of web application and third party integrations, if you wanted an app to access something on your behalf, let's say your email or your calendar, your files, the app asked you for your username and password directly. It stored them it used them and every time it needed to do something it authenticated as you so let that sink in for a second the third party app used your real username and password to log into the main application as you every time it needed to do something. You trusted it that it would only do something it will not leak and when all those good things right now you were trusting that this third party app will not get breached and you trusted that they are taking security well is seriously and sometimes they were not. This was the credential sharing area of the internet and to be fair it wasn't entirely stupidity there was no good alternative if you wanted delegation you shared your keys that was the model right now you could say. That time was bad or you can say we trusted each other so that time was good depends upon your perspective but the failure modes were catastrophic if the third party app got breached your actual password was compromised. Not just your access to that app but your entire account and now you had to the only way for you to do anything about it was to change your password that meant all the third party apps would stop working and it just was not a good approach. And then there were API keys you know API keys long lived secrets often generated once stood in a conflict file and never cleaned up unless there is an audit. So what was born out of this mess not as a specification that fell from the sky fully formed but as an industry response to clear and growing problem we need a way to delegate access without sharing credentials. The core idea was elegant instead of giving an app your password you would go to the service you trusted let's say Google or your bank or your employer's identity provider and you would say. I authorized this app to access this specific thing the service then would give the app a token a limited scope time bound credential that the app could use the app never touched your password if the app got breached that hacker got a token that did one thing for a limited time and not your must key. The internet as it turned out has learned something may be giving your keys to every random app that asked was not the peak of human wisdom or 2.0 codified in 2012 became the foundation that almost everything runs on now it's not perfect we will talk about some of its rough edges but it's fundamentally changed the security model for third party access in a direction for once was actually better. And understanding what. Don't try to like understand those three flows and stuff like that understanding what that the heart means understanding its tokens which brings us to the part of this episode you are going to find yourself coating in meeting. And this is where either I pass in my claim or I totally fail and crash and burn. So let's talk about the token zoo let me walk you through some major type of tokens you are going to encounter in real system and I want to do this differently than the typical dry or tutorial I'm not going to explain each one in terms of the spec I'm going to explain what it does where it shows up and what goes wrong when people may understand that. Because each of these token type has a failure mode so first we'll start with the access token because it is the workhorse this is the thing most people mean when they say token in an API context and access token is a credential you present to a resource server a protected API a service or a data store to prove your authorized to do what you are asking. In one sentence it's your ticket to the API so the client holds it the client presents it the resource server validates it and that's the flow if you have ever seen a request header that says authorization bearer long string you've seen an access token in the wild. So where does it show up literally everywhere a front at application calling a back and API micro services calling another micro services and AI agent calling a tool mobile app accessing your corporate data the access token in the work is the workhorse of modern distributed systems. So what is the failure mode here should and this be perfect a there's a beer concept here that will come to in a second but access tokens are usually short lived but they don't have to be when a system is configured with a long lived access token especially a beer at access token and that token leaks the attacker has working credentials until the token expires. And there is often no mechanism to kill an individual access token in systems that don't implement a revocation and point the token is valid period until it isn't. Now you know what access tokens are let's talk about the ID tokens now this is where I was a little disappointed because this confuses people the most and rightfully so because you know it's called the identity token. So the ID token so it sounds like it should be the most important one we are all identity and access management identities in the name but it's not actually most important token sorry to say this it's actually the most limited in terms of what you should do with it and ID token is an assertion of identity for the client that's it it tells the application who you are. It so the ID token is for the client to read it's not meant to be sent to a resource server as an access credential or an access token this is a distinction that trips people on constantly and ID token is a claim and access token is a capability. So where does it show up in single sign on flows when you log into an application with sign in with Google or your corporate identity provider the application gets an ID token that tells it who you are that's a job done. Now what's the failure mode. This is a big anti patent don't do this using the ID token as an access token and you will hear all sort of claims saying that this should be done and have seen that happen in production systems and the reasoning goes something along these lines. It has identity information in it and we need identity information so we are sending it to our API. Wrong the audience for an odd ID token is the client it is not you being perfectionist about or you know just thinking about what specifications it's about true real word security the audience for an ID token is it is the client if you send it to your resource server your resource server is accepting a token that was never meant for it. And if the ID token comes from a third party provider you are now accepting any token from that provider for any user of that provider that's an audience confusion vulnerability and it has been the root cause of real security incidents. Now let's talk about the refresh tokens because access tokens as you would have guessed right they must be short lived so they are often like they have a time to live or 15 minutes or maybe an hour. Sometimes even shorter and that's intentional but you don't want users to have to re authenticate every 15 minutes so when the access token expires the client takes its refresh tokens. It presents it quietly to the authorization server not the API the authorization server and gets a fresh access token so from a user. users perspective, nothing happened. They are still logged in. The session feels continuous, but under the hood, short-lived tokens are being called continuously. And the refresh token is the mechanism that makes it work. So what's the failure mode? Long-lived non-rotating refresh tokens stored in security, right? So refresh tokens are high-valued targets precisely because they can generate access token indefinitely. If you steal a refresh token and the system doesn't implement refresh token rotation, which is where the refresh token itself gets replaced, you have a credential that works until someone explicit re-box it. So yeah, you got the point. And then there is things think about, called about bearer tokens versus bound tokens. Now, you obviously know about bearer tokens. That's the proof you possess it, you have a trade. But this isn't the type in the same sense, like it's not like the bearer tokens or the bound tokens are in like ID tokens or access tokens or refresh tokens. This is a property that applies to the other types, right? So it is one of the most important distinction in practical token security. A bearer token is exactly what it sounds like. Whoever bears it, whoever presents it, get the access. It doesn't matter who you are, it doesn't matter how you got it, you hold the token, you get the goods. A bound token, sometimes called as sender constant token, is different. You must have guessed it. It's tied or bound to something else, either a client certificate, a device key or a cryptographic proof that you are the entity that obtained with this token, not just someone who found it. And this is called deep op or demonstration of proof of possession. And this is a mechanism that does this with OAuth or sometimes with mutual TLS. That's another approach. So the idea is that the token and the entity presenting it are cryptographically linked, stealing the token string alone is useless without also possessing the private key. So this matters enormously in a high security context. A bearer token that leaks is immediately usable by anyone and a bound token that leaks is a piece of string without the corresponding cryptographic material. So most tokens on the internet today are still bearer tokens because you would assume everything is bound token. But you know, bound tokens are more complex to implement and not universally supported. But the way or the direction that we are going in, I wouldn't be surprised if especially for privileged access and AI agents and high value API integration, this becomes a security standard. But knowing this distinction lets you ask the right question in a design review. Now one more note before we move on, I want to briefly acknowledge the hardware tokens. Although I'm not talking about it because today we are focused on, you know, software tokens flying over STTPS, but hardware tokens are definitely a thing and they are real and they are important and the conceptual model, a time box thing that proves something about you applies to them as well. So now let's get into how OAuth actually uses tokens, right? So let me walk you through an OAuth flow in a plain language, no diagrams, no summulants. And I want to be specific. So let's say you work at a company, you use a calendar app, a third party one, not your company's native calendar client. And on Monday morning, you open the app and click connect to corporate calendar. What happens next is an OAuth flow. The calendar app, we call it the client redirects you to your company's identity provider, your employee's authorization server, or your employer's authorization server, and maybe it's Azure AD or Entry AD, maybe it's Octa, maybe it's something your company built, which is a really stupid idea. But you end up on a login page, you recognize, you log in so far, so normal. But here is the key step, the authorization server now asks you whether you want to grant the calendar app permission to read your calendar, not write, not delete, but read. And maybe it shows you a screen that says this app is requesting access to read your calendar in events and you can click allow or deny. But since you initiated it, you click allow. Now, what happened there is called consent, right? You would have heard the things about consent management. This is what it is. You the resource owner, because it's your calendar explicitly authorized the client to access something on your behalf. Outh is at its core a delegation framework. You didn't give the calendar app your password and you instructed your identity provider to give the calendar app a limited credential. The authorization server now redirects you back to the calendar app along with an authorization code, just a one-time code, very short-lived and good for a few seconds to a minute. The app takes that code, presents it to the authorization server from its back and along with its credential proving it's the real calendar app. And again, exchange it gets two things and access token and no point for guessing a refresh token. So the access token goes to the calendar API. The API validates it, checks the signatures, checks everything that was issued for this API specifically, check that it hasn't expired, check that it has the scope to read calendar events and if everything checks out, it returns your calendar data. But what about the refresh token? The refresh token stays in the app's secure storage. When the access token expires, the app uses the refresh token to quietly get a new one. You never see this, you never see a working, you just see a working calendar app, you will not be prompted for reauthentication. Now, let me call out the three things that matter most in that flow because this is where token security actually lives. First, this is important, guys. First, audience, the access token says who it's for, which resource server is supposed to accept it. If an access token is supposed to be for the calendar API, the calendar API should check that it's actually the intended audience. If the token shows up at the email API, the email API should reject it because the token wasn't issued for it. A lot of audience or a lot of systems skip this check because they want to reuse the token across multiple systems or skip it implicitly and that creates a vulnerability called confused audience or audience confusion, where a token issued for one service get accepted by another. You should always ask in a design review, does every resource server validates the resource claim or the audience claim? So, there is a claim in the token which is AUD. Now, second, so the first was the audience and the second is the scope. The access token encodes what a client is allowed to do. In our example, read calendar events, not write, not delete, not access other services, a scope should be as narrow as possible for the task at hand. In real world, you find scopes like full access and admin because they were convenient to implement and nobody pushed back. That's a problem. Broadscope means a lead token can do more damage and usually you can go back to your security policy and standards and it will have one around least privileged access and you can use that security standards to influence the design review of being more granular in the scope. So, in every review, ask what is the narrowest scope this actually needs. And third is the lifetime. How long is this token valid? 15 minutes and a year fully configurable is not an answer. What's the default? What's the range? What happens when it expires? A token lifetime is a direct translation of if this credential leaks. How long does this attacker have? That's it. That's what lifetime means translated into risk. So, let me tell you one gotcha that I have seen repeatedly. Teams set very long token lifetimes because it's annoying when things expire and frankly, I understand the impulse. User complain when they get logged out, support tickets go up, product managers get Angie. So, someone sets the access token lifetime to 24 hours or a week and I want you to know this actually happens to infinity. A 24 hour access token that leaks is a 24 hour window for an attacker. A week long token gives you a week and infinite lifetime token is functionality. A password that doesn't expire, it just harder to read and when someone tells you their token lifetime is very long for user convenience but they are showing saying is our risk management strategy is hoping nothing leaks. So, let's talk about one of my favorite categories of bad security claim than never expiring token. You have heard this may be a vendor, may be an internal developer, our session never expires, user. love it. We should long lift tokens so the user experience is seamless and it's a non-expiring API key for the integration. It's just easier that way. Those statements can mean several different things and the distinction matters a lot. First, there's a difference between token lifetime and authorization lifetime. Those are two different things and conflating them is how you end up in trouble. Token lifetime is how long a specific token string that actual credential that specific jot or opaque blob is valid. It's baked into the token itself or enforced by the server that validates it. When the token's lifetime ends, that string stops working. Authorization lifetime force is how long the underlying grant the user's authorization, the permission relationship between the client and the resource is allowed to persist. So it grant can exist long after any individual token has expired. That's by design. That's how the refresh token model works. A well-designed system creates the illusion of a seamless never-ending session through short-lived access tokens, a longer-lived refresh tokens and rotation on each use and the ability to revoke the refresh token and therefore the whole grant at any time. The user experience looks like it always logged in. It just works. The security architecture is access token live for 15 minutes. Refresh tokens rotate and are revocable and we have got a normally detection on refresh token usage patterns. That's not a never-expiring session. That's a very carefully engineered short-expire system that looks seamless from the outside. There is a difference and it matters when something goes wrong. So let's talk in scenarios. A company builds a CI/CD pipeline integration and an engineer generates a personal access token with this scope, full repository access and a lifetime of never. They put it in the pipeline configuration and it works great and 18 months later the engineer leaves the company. Eight months after that a contractor accidentally commits a debug log to a public repository and the log contains the token and someone finds it within hours. Now the token is still valid. It has never expiring lifetime. It has full repository access. The attacker uses it for 11 days before someone notices unusual commit activity. 11 days of access to every private repository the company owes. Now the incident response question is how do we kill this token and the answer is go find where that engineer's credential live and hope the account still exists and revoke it manually. If the account has been deprovisioned it's a journey through service desk tickets and if the token was issued under a shared service account, good luck finding protocol. Let's take another scenario. Same company, same CI/CD integration but built properly. Access token, not personal access token, access tokens, live for 15 minutes. My another gripe with personal access token says it's just like bypassing MFA which is your strongest security control but we will talk about it in some other episode. So scenario two we were talking about the next scenario. Access token live for 15 minutes and they are issued to the pipeline via client credential flow, machine to machine, no user involved and the client secret for the pipeline rotates every 30 days by an automated secrets manager and token lifetimes are enforced at the resource server. So 18 months later same accidental commit to a public repository. Same token string in the debug log and somebody found it. The token expired 14 minutes ago. It's worthless. The attacker has a string that doesn't work and by the time they figured out why it has been rotated twice more. This is the argument for short access token lifetime made concrete not as a specification recommendation but as a incident response map. Now here's an uncomfortable nuance. You need to understand that short lived access tokens don't protect you if your refresh tokens are long lived or non-rotating or unmoneted. Because if I steal your refresh token I can keep minting new access tokens indefinitely. The 15-minute access tokens gives me a 15-minute window unless I also have the refresh token and then I have whatever window the refresh tokens lifecycle lifetime represents minus the detection time. This is where token security is a system property and not an individual token property. The chain is only as strong as its weakest link. So short access tokens with long standing refresh tokens is not a robust security model. It is a short access token bolted on a poorly managed long lived credential. So I want to spend some time on some myths not to be mean but because these are the statements that end up in architecture reviews vendor pitches and engineering all hands and they sound reasonable until you push on them. So let me give you the lines the things that get said and then let me give you what they actually mean and the question you should ask next time you hear them drum roll please. So we are secure we use jords. Jords come up in almost a JWT. Come up in almost every token conversation and they get treated like a security property they are not there a format. Jords stands for JSON web tokens. It is a standard for encoding token information as JSON object signing it and you know it's a format. What is Jords gives you is a self-contained verifiable token. The receiving server can validate it its signature without calling back the issue. That genuinely useful it's not security by itself the security of a Jords depends on who issued it whether the signature algorithm is strong whether the receiving server validates the issue or an audience how long the token lives and where the token is stored client side none of these are guaranteed by we use Jords all of these are independent configuration choices your team makes. Now there is an oldie but goody vulnerability where Jords that declared their own algorithm were accepted even when the algorithm was said to none meaning the signature. The token said I valid no signature needed and some libraries believed it that's not theoretical that's a real class of vulnerabilities that has appeared in real products the Jords specs allowed it and using Jords didn't prevent it so when someone says we use Jords the grown up response is good for you buddy who's the sure what algorithms are you signing with and does your server validates the audience claim right just say that in a nicer manner that I did because if they can't answer those three questions without checking we use Jords is not a security statement now the second myth is our token never expires users love it we have already spoken a lot about it right the pressure to make most tokens long lived usually comes from product teams and customer experience matrix and that's a legitimate pressure the answer is not most make tokens infinite the answer is built seamless token renewal so the user never sees the expiry so move away from never expiring token to a seamless user experience because that is the end goal from the start the third myth is we just put tokens in local storage because it's convenient and this one is ever green because local storage sounds fancy but it's a browser storage mechanism it persists across page loads it's easy to use and it's accessible to any Java script running on that origin including injected Java scripts from a cross side scripting attack so if you store an access token in local storage and your application has an excesses vulnerability even the one that you haven't found yet or the myth has a found an attacker who successfully injects a script into your page can read that token with a single line of Java script I'll say that's very simple right on an audio podcast I can tell you that single line is local storage dot get item that's it now fancy hacking stuff here there's the single line local storage dot get item so the more secure option for web application is to use stdpl only cookie for token storage and stdpl only cookie cannot be read by Java script it is transmitted by the browser automatically with request to the same origin and it's not immune to all attacks CSRF is a concern you manage with CSRF tokens, but it takes java script. base exfiltration of the table. So putting tokens in a local storage because it's convenient is a direct trade of security surface developer for for developer convenience. So another myth that we want to talk about and I'm really getting into it. I thought, you know, we are almost 40 minutes, but I'll just talk about a couple more myths. So it's a super long random bearer tokens. We are safe. And this one comes from a reasonable intuition that longer secrets are harder to guess and that's true. A 265 to 56 bit random token is effectively unguessible. Nobody's brute forcing that. But you know, the length and randomness of a bearer token is defense against one specific attack guessing. It's not a defense against logging or exfiltration or inside a threat or missed configurations or storage or dozen of other ways credentials end up somewhere they shouldn't be. So essentially what I mean by that is once a bearer token is out in the wide length means nothing because you can just copy paste it. Right. Another myth is we use the ID token every year. It's basically the same thing. So we covered this, right. ID token is for the clients. Okay. So I really love this section. I even talking about it, but I'll do one more and this would be for our favorite topics the AI. And then we'll move on. So this is the next myth. The agent handles authentication. We don't need to worry about token management and that is the new myth and AI agents get deployed into enterprise environments. The assumption often is the agent platform handles all of this. The developer just calls the API and token are an infrastructure problem. There's the issue. The agent that calls APIs needs credential. Those credentials are tokens. Those tokens have lifetimes, scopes and revocability properties. And the agent platform may be doing things you are never reviewed storing tokens in ways you have found alarming. So the agent handles it is the 2025 version of the developer handles it. And if you have been in this industry long enough, you know how that that story usually ends. So let's start wrapping it up here. How do we interrogate any token story? So I'll give you something practical because I made a bold claim and I hope I'm being able to live up to it. Three questions, that's it. Three questions that you can ask in any design review, any vendor call, any architecture decision, any post incident debrief, any first dates, basically anywhere where tokens are involved. These questions will cut through more nonsense and less time than any specification you will ever read. So question one, who issued this token and why do we trust them? The question exposes implicit trust relationship and in modern systems, you often accept tokens from issuers. You have never deliberately decided to trust. It just happened during integration. Okay, question two, what exactly does this token allow for which system and for how long? But are you checking scope, audience and lifetime? So basically all three. When these questions don't have crisp answers, it usually means the token architecture was built by someone who understand or understood one part of OAuth issue a token, but not the governance model around it. That's fixable, but you have to ask first. And question three, if something goes wrong, how fast and how completely can we kill its power? So this is the incident response question. And this is the one that I've seen that gets kept most often. These three questions don't require you to have memorized rfc6749, though I would advise you to read it, but these questions without any sort of memorization require you to know what matters and to be willing to ask until you get a real answer. Remember, it's all super simple under the hood. The identity at the conceptual level is super simple. Everything should be able to be explained by the first principle thinking. The implementation could be hard, but the explanation needs to be simple. So let's wrap it up here. So let's go back to the conference room where it all started. Same 12 people, there were 12 people, right? Yep, so I would assume. So same 12 people, same vendor and same spaghetti architecture slides, same confident talks about jords, period tokens, never expiring sessions, agent AI security and zero trust network design. But this time you are in a room with everything we have covered today in your back pocket. So when they say jord-based security, you ask, what's the signing algorithm and does your server validate the issuer and the audience? When they say our session never expires for seamless user experience, you ask, what's the blast radius if the token is compromised and what is the revocation story? When they say our agent AI platform handles all token management, you ask, what are the token lifetimes and scopes for agent credentials? And can you show me how you would revoke a specific agent's access in an incident? Now, in some cases, the room will go quiet, but this will not go quite in an awkward way. This will go quite in a good way because all of the people there, the product managers, the engineers, even the vendors, they have the same goal to secure a company and provide you a functionality. And in the way when a vendor realizes they are talking to someone who has done the work and either as answers that satisfies you, which means you have found a vendor worth talking to or doesn't, which means you have saved yourself from a very expensive mistake. So the junior architect who asked the first question, she was right to ask. The mistake wasn't hers, it was the rooms for letting it go unanswered. You don't let it go unanswered. We have talked about this before. One of the reasons I love identity is that it's rooted in first principle thinking. At its core, everything makes sense. Most of the terms are just common sense and disguise. So it never be afraid to ask the basic questions. Why do I trust this? How do I revoke the access? A token at the end of the day is just a small piece of data and no small piece of data should ever scare us. So here is where I will leave you. Tokens aren't magic, they are permission slips with an expiration date, highly specific, cryptographically signed, tightly-scoped permission slips that are a tire digital infrastructure depends on. The trick is knowing who signed them, what door they opened, how long they worked, and how to take them back the moment you need to. That's the whole thing that's the tokens. Go ask better questions in your next meeting. Until next time, this is Rohit, your identity navigator.