I was poking around an old repository of mine the other day—something I haven't touched in years—and I found a static service account key file just sitting there in a subfolder. It was like finding a digital unexploded landmine in my own backyard. It honestly made me sweat a little bit, thinking about how many times I might have cloned that repo or who else might have had access to it over the last few years. Today's prompt from Daniel is about that exact anxiety, specifically looking at the authentication landscape in Google Cloud as of late March, twenty twenty-six. We are living in a world where the "Secret Zero" problem has fundamentally evolved. It is no longer just about where you hide your keys; it is about the fact that if you have a key at all, you have already lost.
It is a timely concern, Corn, and your "landmine" analogy is more accurate than you might realize. I have been pouring over the Mandiant M-Trends twenty twenty-six report that just dropped on March twenty-third—literally three days ago. The data is sobering, to say the least. Identity-based attacks are no longer just a trend or a secondary concern; they are the primary theater of war. We are seeing groups like REDBIKE, which some researchers call Akira, and AGENDA, also known as Qilin, shifting their entire strategy. They are not just looking for unpatched servers or zero-day exploits in your firewall anymore. They are targeting the identity management planes directly. They want your tokens, they want your session cookies, and most importantly, they want those static keys you just mentioned. If you have a static key sitting in a repository, you are effectively leaving the back door wide open with a welcome mat that says "please encrypt my data and hold it for ransom."
It feels like the era of being casual with credentials is officially dead. The "Secret Zero" paradox—the idea that you need a secret to get a secret—is something we talked about back in Episode fourteen seventy-four, "The End of API Keys." But today, Daniel wants us to dig into the actual cliff notes for developers who are building web apps in this high-stakes environment. We are looking at the current state of OAuth, the shift in service tokens, and those legacy forms that everyone seems to be clinging to like a security blanket that is actually made of flammable lace.
That is a vivid image, and unfortunately accurate. The biggest shift we have seen in the last year is the move toward the Google Auth Platform. This was a dedicated console section launched in April twenty twenty-five to centralize how we manage clients. Before that, things were a bit scattered across the IAM and APIs sections, and it was easy to lose track of what client ID was doing what. Now, it is a unified command center. But with that centralization comes a much shorter leash from Google. They are moving away from the "set it and forget it" mentality of the twenty-tens.
Right, they are not just giving us better tools; they are enforcing better hygiene. I noticed that starting in June twenty twenty-five, Google began a policy of automatically deleting OAuth clients that have been inactive for six months. That is a pretty aggressive way to reduce the attack surface. It is like the city coming by and boarding up houses that have been empty for too long so squatters do not move in. If you are a developer with a "test" project from three years ago that still has an active OAuth client, Google is basically saying "use it or lose it."
The "squatter" in this case is a threat actor who finds an old, forgotten client ID with overly broad permissions. For developers building web apps right now, the non-negotiable standard is the Authorization Code Flow with PKCE, which stands for Proof Key for Code Exchange. I still see people trying to use the implicit flow because it feels easier or they are following an old tutorial from twenty-nineteen, but that is a massive mistake in twenty twenty-six.
Explain the PKCE requirement for the people in the back, Herman. Why is that the gold standard now instead of just the regular old client secret? I think a lot of people still think PKCE is just for mobile apps.
That is a common misconception. The core problem with the traditional flow on the web is that the client secret is incredibly difficult to keep secret in a browser environment. If it is in your JavaScript, it is public. PKCE solves this by creating a dynamically generated secret for every single authorization request. The client creates a "code verifier"—just a high-entropy random string—hashes it to create a "code challenge," and sends that challenge to Google. When the authorization code comes back, the client sends the original verifier. Google hashes it and compares it to the challenge. If they match, it proves the entity requesting the token is the same one that started the flow. It prevents authorization code injection attacks where an attacker intercepts the code and tries to use it themselves. In twenty twenty-six, if you aren't using PKCE, you're essentially leaving your tokens on the sidewalk.
It is basically a one-time-use secret that expires in seconds. But here is where I see a lot of developers trip up, even the ones using PKCE. They get the identity token on the frontend, they see the user's email address in the claims, and they just trust it. They send that email string to their backend and say, "hey, this is Corn, let him into the database."
That is a catastrophic security anti-pattern. A March twenty twenty-six documentation update from Google explicitly states that you must never trust a claim that comes from the frontend. The only secure way is to send the entire identity token—the "jot," as we call it—to your backend and then have your backend verify it using the Google API client libraries. Those libraries do the heavy lifting of checking the cryptographic signature against Google's public keys. If you just grab the email string from the browser's local storage, an attacker can just type in whatever email they want into their console, and your backend will believe them. You have to verify the signature, the issuer, the audience, and the expiration.
It is the digital equivalent of someone showing up at a club with a VIP pass they printed at home on a deskjet printer and the bouncer just nodding and letting them in because it has the right logo on it. You have to check the watermark. And speaking of watermarks, we should talk about that alias persistence vulnerability from late twenty twenty-five. That one was sneaky because it exploited how Google handles corporate identities.
It was a fascinating discovery. Essentially, because Google allows users to have multiple email aliases, an employee who left a company could sometimes retain access if their identity was tied to an alias that was not properly scrubbed from the application's internal database. The recommendation now, which is critical for any enterprise app, is to validate the "HD" or host domain claim in the OpenID Connect token.
So even if the email looks right—like "
corn@company.com"—you check the host domain claim to make sure it is actually coming from the specific corporate workspace you expect. It prevents someone with a personal Gmail account that happens to share an alias name from slipping through the cracks. It is all about narrowing the scope of who can even attempt to knock on the door. Now that we've covered the client-side, let's look at how we handle service-to-service communication without the dreaded JSON key file. Because that's where the real architectural shift is happening.
The JSON key file is a relic. It belongs in a museum next to the floppy disk. Google is pushing everyone toward short-lived tokens and something called Workload Identity Federation. This is the centerpiece of the "secretless" movement.
I love the idea of Workload Identity Federation in theory, but I think for a lot of people, the idea of not having a key file to upload to their server feels like magic. How does a server in an Amazon Web Services data center or a GitHub Action runner talk to Google Cloud without a secret key? It feels like we're breaking the laws of digital physics.
It relies on a trust relationship. Instead of a shared secret, you establish a federation between the external provider—like AWS or GitHub—and Google Cloud. When your GitHub Action runs, it already has an identity token issued by GitHub. It presents that token to Google's Security Token Service, or STS. Google looks at it, says, "I trust GitHub, and I see this token is for the specific repository and branch I expect," and in exchange, it hands back a very short-lived Google Cloud access token. No static secret ever exists. No key to leak. No key to rotate. It is a beautiful, ephemeral handshake.
It really is the end of the "Secret Zero" paradox. We used to need a secret to get a secret, and it was just turtles all the way down. Now we use identity as the root of trust. And Google just made this easier to manage for large teams with the General Availability of Service Account Principal Sets on March third, twenty twenty-six.
The Principal Sets are a game changer for IAM management at scale. Before this, if you had a hundred service accounts across different microservices that all needed the same set of permissions, you had to manage them individually or through complex, error-prone scripts. Now, you can define a group of service accounts as a single "principal set" and apply policies to the whole group. It reduces the chance of "configuration drift"—that situation where ninety-nine accounts are secure but one was forgotten during an update and still has "Owner" permissions. In twenty twenty-six, "Owner" is a four-letter word in security circles.
I am glad you mentioned owner permissions. I feel like the "roles slash iam dot service account token creator" role is the most important role nobody talks about. If you want to impersonate a service account—which is how you should be doing things now—that is the only way to go.
You are right. Impersonation is the modern alternative to downloading a key. Instead of having a high-privilege service account key sitting on your laptop, you give your personal identity—or a lower-privilege service account—the "Token Creator" role on that target account. Then, when you need to perform an action, you ask Google to generate a one-hour token for that service account on your behalf. It is all logged, it is ephemeral, and it requires you to be multi-factor authenticated yourself. It is the death of the shared password for services.
It is also worth noting that for really sensitive operations, you can use the Security Token Service to request tokens that are even shorter than the default hour. You can go down to fifteen minutes. If you are doing a critical production deployment, you get a fifteen-minute window. If an attacker somehow intercepts that token, it is a useless piece of data before they can even figure out what to do with it. It’s like a mission impossible message that self-destructs.
That kind of token hygiene is what separates the professionals from the targets in twenty twenty-six. Moving from the theoretical security of OAuth and Federation, let's talk about the practical reality of the legacy cleanup happening right now. Google is being quite ruthless with deprecations lately, and for good reason. The legacy Google Sign-In SDK is officially on the chopping block.
I saw that. As of March sixth, the migration guide was updated to point everyone toward the Android Credential Manager. It is a bit of a headache for developers who have been using the old "play services auth" library for a decade, but the new API is much cleaner. The biggest change is that it strictly separates authentication—proving who you are—from authorization—getting permission to access specific data like Drive or Calendar.
That separation is vital. The old way often conflated the two, leading to "permission bloat" where apps asked for way more access than they needed just to let a user log in. The Credential Manager also integrates better with passkeys, which is the ultimate goal for phishing resistance. We talked about this in Episode nine fifty-eight, "The Two-FA Fallacy." If we can get users off passwords and onto biometrically backed passkeys, groups like REDBIKE and AGENDA lose their biggest weapon: the stolen credential.
Speaking of stolen credentials, that Aembit report from January twenty twenty-six was a massive wake-up call. They found that thirty percent of cloud intrusions in twenty twenty-five involved leaked static credentials like API keys. And yet, I still see people using API keys for things that should absolutely be handled by OAuth or service accounts.
API keys are essentially just a string of text. They have no inherent expiration, they do not support multi-factor authentication, and they are usually tied to a project rather than a specific identity. Google is increasingly labeling them as "legacy" for anything sensitive. If you are just hitting a public Map API to show a store location, sure, a key is fine. But if you are accessing user data or infrastructure, using an API key in twenty twenty-six is like using a padlock from a child's diary to secure a bank vault.
It is also interesting to see how this is affecting the security operations side. Google SecOps—which most of us still want to call Chronicle—finished a big migration on March eighth. They moved from their legacy role-based access control to the standard Google Cloud IAM console. It sounds like a minor administrative change, but it means security teams can finally manage their own access using the same fine-grained, feature-based policies as the rest of the cloud. No more silos.
It is all about consistency. The more fragmented your identity strategy is, the more gaps there are for someone to slip through. Even things like Gmail are locked down now. Since the March twenty twenty-five cutoff, any legacy protocol like IMAP or SMTP that does not support OAuth two point zero is just dead. You cannot even use "basic auth" with a password anymore. It’s OAuth or nothing.
Which brings us to the big one. The MFA mandate. This is the thing that is going to have the biggest impact on the average user and developer. CISA, the Cybersecurity and Infrastructure Security Agency, has been beating this drum for years, saying that multi-factor authentication reduces hacking risk by ninety-nine percent. Google says seventy percent of their active users had already adopted it before the mandate, but that last thirty percent is always the hardest to move.
By the end of twenty twenty-six, every federated identity accessing Google Cloud resources must use multi-factor authentication. There are no exceptions anymore. This is a massive win for American infrastructure security. If you are a developer building an app that uses Google for auth, you can basically assume that the identity you are getting back has been multi-factor verified. That is a huge weight off your shoulders, but it doesn't mean you can get lazy with how you handle the tokens themselves.
You still have to handle the secrets you do have correctly. We cannot talk about this without mentioning Secret Manager. It is not enough to just not put keys in your code; you have to put them somewhere secure. And the new integration with Gemini Cloud Assist is actually pretty clever. It can suggest the most restrictive roles for your secrets based on how your application is actually using them.
I was skeptical of the AI integration at first, but the role suggestion feature in Gemini Cloud Assist, which has been in preview since December twenty twenty-five, is actually very helpful for avoiding permission bloat. It looks at the access patterns and says, "hey, you gave this service account full access to the secret, but it only ever reads it once a day. Why not give it a more limited role?" It is helping developers follow the principle of least privilege without having to be an IAM expert or spend hours auditing logs.
It is like having a very pedantic security auditor sitting on your shoulder, but one that actually helps you fix the problems instead of just writing a mean report at the end of the quarter. I think the cliff notes for developers here are pretty clear. Stop using keys, start using claims. Use PKCE for your web flows. Verify everything on the backend. And for the love of all that is holy, pronounce JWT as "jot."
I am glad you brought up the pronunciation. It makes the conversation so much smoother. If we are summarizing this for someone building an app today, the checklist is simple. One: move to the Google Auth Platform console and clean out those inactive clients. Two: implement the Authorization Code Flow with PKCE and perform backend verification using official libraries. Three: use Workload Identity Federation for any service running outside of Google Cloud—no more JSON keys in GitHub Secrets. Four: embrace the MFA mandate because it is your best friend in the fight against REDBIKE and AGENDA.
And five: check your tokens. If you are handling sensitive data, use the Security Token Service to shrink those lifetimes. An hour is a long time in a cyberattack. Fifteen minutes is much better. It is about making the window of opportunity as small as possible. We have to remember that identity is the new perimeter. Your network does not matter if I can just walk in with a valid identity token I found in a public repository or a misconfigured S3 bucket.
It really is a shift in mindset. We are moving from a world where security was a wall you built around your network to a world where security is a continuous verification of identity. It acknowledges that the walls are always going to have cracks, so you have to make sure the people inside are who they say they are at every single step. It is a bit more work upfront, but it beats having to explain to your board why a group like AGENDA is holding your database for ransom because you liked the convenience of a static JSON key.
Convenience is the enemy of security. Always has been. But the tools we have in twenty twenty-six are making it so that the secure way is not necessarily the hard way. Workload Identity Federation is actually easier once you get it set up than managing a bunch of key rotations and worrying about who has copies of those files. It is the difference between carrying around a heavy ring of brass keys and having a biometric scanner on your thumb. One is objectively better, even if the transition takes a minute to get used to.
The Mandiant report makes it clear that the groups targeting us are professional, well-funded, and patient. They are looking for the path of least resistance. If you follow these standards, you are making yourself a much harder target. Identity management is the foundation of your defense. If you get this right, everything else—from encryption to logging—becomes much easier to manage.
Well, I feel a lot better about that old key I found. Mostly because I deleted it and revoked the service account immediately after I saw it. If you are listening to this and you have a feeling there might be a key file lurking in your downloads folder or a random repo, go find it. Right now. We will wait.
Actually, do not wait. Go do it. The REDBIKE guys are not waiting. They are scanning public repositories every second of every day.
Fair point. Thanks for the deep dive, Herman. This has been a solid look at where we are with Google Cloud auth. It is a moving target, but at least we have a map.
Always a pleasure to dig into the documentation, Corn. There is a certain beauty in a well-implemented identity flow. It’s like a perfectly choreographed dance where everyone knows their place and no one gets in without an invitation.
Spoken like a true nerd. Thanks as always to our producer Hilbert Flumingtop for keeping the gears turning behind the scenes. And a big thanks to Modal for providing the GPU credits that power this show. We could not do this without that kind of specialized infrastructure.
This has been My Weird Prompts. If you are finding these deep dives helpful, we would love for you to follow us on Spotify or wherever you get your podcasts. It really helps the show grow and allows us to keep digging into these technical rabbit holes.
Or you can find us at myweirdprompts dot com for the full archive and all the technical details we talked about today. We have over fifteen hundred episodes in the vault now, so if you have a niche technical question, there is a good chance we have poked at it before.
Until next time, keep your tokens short and your identity verified.
See ya.
Goodbye.
