Identity: The Kill Switch For API-Driven Digital Sovereignty

00:00:04:38 - 00:00:28:45 This is a little bit about me. I’m the Technical Director of Professional Services at Curity, so I work with our customers every day to help them understand identity and API challenges, and to create solutions. That’s what we do in our team. We’re a group of identity specialists, and I’m also a former Java developer.

00:00:29:14 - 00:00:44:23 I still do a little bit of that. I’m also an avid Pokémon Go player, so if anyone here wants to be friends, hit me up. And if you know Pokémon Go, level 46 is not really something to brag about.

00:00:44:27 - 00:01:12:23 But more importantly, just a few years ago, there was almost a race to the cloud. Everybody wanted to leave their on-premise environments and move to the cloud to access platforms that were easier to maintain. In many cases, you hand over large parts of your systems to other parties, which can cut costs and simplify operations.

00:01:12:27 - 00:01:36:37 And of course, it’s very tempting. But recently, with new legislation and regulations in play, the decision isn’t as straightforward anymore. You always need to think about where your data is stored and how it’s managed.

00:01:36:42 - 00:02:03:30 Legislation might even mean you’re not allowed to put certain data in the cloud. So it’s not an obvious choice, and it requires thorough planning. What I’m saying is: you need to keep control of your data. You need to know where everything is stored, and how people and machines are accessing it.

00:02:03:34 - 00:02:31:31 You also need to design for resilience in your platform. This isn’t new. It’s something you’ve already been doing in your systems, even on-premise. You prepare for the database going down, and in many cases you already have a standby copy so you can replace it and continue as if nothing happened.

00:02:31:35 - 00:02:57:12 The same thing applies to your APIs. You already have pipelines in place so that when monitoring detects an API outage, you can quickly spin up a new node. Suddenly you have a new instance answering requests. The same can be said about your API gateway, where you may already have a failover cluster.

00:02:57:12 - 00:03:29:16 That way, you can reroute traffic to another cluster and continue serving requests. So this isn’t news. Deployments have looked like this for quite a while. And in the cloud, you can do pretty much the exact same thing. We just need to keep doing it.

00:03:29:20 - 00:03:53:20 A common factor in all these platforms is that we also need control over who accesses them, whether it’s users, applications, or machines. They need proof that they’re allowed to access the system. They need a token. That’s why we strongly believe in a token-based architecture.

00:03:53:21 - 00:04:22:16 Every request should be authenticated by a token, and that token needs to come from somewhere, most likely an OAuth server. But it could also be another protocol that helps us create this proof. The question is: if we’re not in control of the identity system, what happens if it goes down or becomes unavailable?

00:04:22:20 - 00:04:49:45 This is what I mean when I say identity is the kill switch. Whoever controls your identity system has so much control over your platform that they can effectively shut it down. If users can’t log in, they can’t access services. And that is directly connected to your revenue stream. If users can’t log in, they can’t buy things, and they can’t access their own data.

00:04:49:46 - 00:04:59:42 So having full control of that switch is key for your business.

00:05:00:21 - 00:05:26:38 We need to take control of the switch. That can mean hosting the identity system yourself, or at least having full control over where it runs, its uptime, and how it stores data. It doesn’t mean you need to host it in your closet, but you do need control over where it is and how it operates.

00:05:26:38 - 00:05:51:22 This is important not only to prevent someone from being able to shut you down, but also to comply with regulations. So we need the same type of protections in place that we already have for other systems. For identity systems, we need failover clusters, the ability to spin up new nodes, and resilience.

00:05:51:22 - 00:05:59:31 And depending on your use case, we can also…

00:06:00:19 - 00:06:26:44 …hedge our bets and deploy across multiple regions and even multiple cloud providers, to ensure we never lose control of the identity switch.

Now, we’re going to talk a little bit about authentication methods. We have an identity system, and we authenticate users, but different authentication methods have different properties. They’re not all the same. They offer different levels of security, different dependencies, and different types of data.

00:06:26:44 - 00:06:38:01 They can also give you different kinds of user information.

00:06:38:12 - 00:07:01:00 Let’s start with national ID authenticators. I’m Swedish, and I use Swedish BankID almost every day. In Sweden, we use it for pretty much every service. We use it for retail, for banking, and for many other systems.

00:07:01:04 - 00:07:28:37 It’s a very good method, but not every country has something like it. These solutions differ in UX, convenience, and adoption. But one thing they have in common is that they are high-assurance authentication methods, and they often provide user data, not just an identifier.

00:07:28:37 - 00:07:31:40 Most of the time.

00:07:31:44 - 00:07:57:30 But when we rely on this type of method, what we’ve really done is move the switch. The switch is now the national ID provider. If Swedish BankID is down, pretty much nobody can log in to anything. We had a situation about half a year ago where it was down for three hours, and it made headlines everywhere.

00:07:57:34 - 00:08:25:33 So we need a break-glass scenario. When this provider is down, we need to offer alternatives. We need other ways for users to log in.

Of course, username and password works. Everybody knows it. It’s simple, but not the most secure method. We all want to move away from it, but at least it has no external dependency. It can be handled locally in our service.

00:08:25:37 - 00:08:37:13 So it’s still useful as a fallback.

00:08:37:17 - 00:09:03:06 Time-based OTP is a step up, meaning authentication apps that generate one-time passwords. It doesn’t have an external dependency, but it does rely on shared secrets. We need to set up a shared secret between the user and the server in order to use it.

00:09:03:10 - 00:09:23:43 Passkeys, in my personal opinion, are another step up. First of all, we don’t need shared secrets. They’re based on asymmetric cryptography, so we only need the public key on the server. It’s also convenient for users, since passkeys can be synced within their ecosystem, allowing them to use multiple devices.

00:09:24:12 - 00:09:41:11 So you don’t always have to log in on the same device. And it has no external dependency for the server. Of course, for the user, there can be issues if they rely on syncing and the device hasn’t synced yet. In that case, they may need connectivity to their ecosystem.

00:09:41:15 - 00:10:15:37 But what all these methods have in common is that we need some kind of centralized user data. To use them as break-glass methods or as alternatives, we need registered users. We need to provision shared secrets, or key pairs for passkeys. That might be easy if you have a single server and don’t need to replicate data.

00:10:15:37 - 00:10:44:49 But in a multi-region setup, it becomes harder. Can we really sync that data across regions? Should the user be able to log in everywhere? That creates challenges, and legislation doesn’t make it easier.

And this is where verifiable credentials come in. Verifiable credentials are an authentication method that puts the user in control.

00:10:45:03 - 00:11:08:11 The user holds the data about their identity and can choose what to share, and with whom. There is no online actor required at runtime. It’s still early days for verifiable credentials, but adoption is growing, and it looks like we’re heading in that direction.

00:11:08:15 - 00:11:35:20 It’s a standardized method, standardized by the OpenID Foundation and others. The issuance and presentation protocols from the OpenID Foundation enable decentralized identity, where I can hold my credential myself, without needing to store it in a cloud. I can present it whenever I need it.

00:11:36:00 - 00:12:01:32 Verifiable credentials are often described as enabling self-sovereign identity, meaning the user keeps control of their data and doesn’t have to share it with everyone. But it also enables secure authentication on the server side without needing to know the user in advance. We don’t need to store lots of information before the user shows up the first time.

00:12:01:32 - 00:12:19:31 So it works very well as an alternative to national IDs. And ideally, national IDs will eventually become verifiable credentials, so we don’t need an external service dependency.

00:12:20:00 - 00:12:39:30 If I have a verifiable credential and the server accepts it, I can go to the identity system and present my credential. I can also choose what data I share at that moment. My credential may contain a lot of information, but in one situation I might only want to share my name and my employer.

00:12:39:30 - 00:13:09:06 That’s up to the user. The server then decides if that’s enough data and whether to allow access. Typically, the key thing to trust is the issuer of the credential. If the credential is issued by a small unknown company somewhere in Stockholm, I might not trust it. But if it’s issued by a bank or a government, trust is higher.

00:13:09:10 - 00:13:34:49 So the server can maintain a list of trusted issuers. For example, it may trust only governmental issuers, or it may trust any issuer depending on the use case. The key point is that we don’t have an external runtime dependency, and we don’t need to store as much PII in the system.

00:13:35:03 - 00:14:04:07 Verifiable credentials are still new, but we’re already seeing adoption and emerging use cases. I think we’ll see things accelerate because of upcoming EU legislation. Wallets are expected to be regulated by the end of 2026, and I believe all 27 member states will need to support this.

00:14:04:22 - 00:14:12:20 So we’re not fully there yet, but I think adoption will come fairly soon.

00:14:12:24 - 00:14:45:42 With authentication methods that are resilient, we also need to extend that resilience to API access. When a user logs in and receives a token, we have user data in the system that we may need to share internally. But we can’t always convey that data back to external applications, both for regulatory and privacy reasons.

00:14:45:46 - 00:14:58:30 Applications outside our platform don’t necessarily need access to that user data, but in some situations they might still see it.

00:14:59:00 - 00:15:25:07 So I want to talk about some patterns that can help. We may have mentioned the Phantom Token pattern a couple of times, but it’s worth repeating here. The Phantom Token pattern uses standard specifications by combining multiple standards together.

00:15:25:11 - 00:15:37:27 It relies on the client requesting access and being issued a token.

00:15:37:31 - 00:16:01:03 This token represents information about the user, but the format does not expose that information. It’s an opaque token, basically just a random string. It doesn’t mean anything to anyone reading it. It only has meaning to the authorization server.

00:16:01:07 - 00:16:27:47 When the application calls an API, the API gateway intercepts the request, dereferences the token, and exchanges it into a JWT, which is readable and contains the claims in clear text. That allows the API to validate the claims and authorize the request based on that information.

00:16:28:01 - 00:16:48:26 So the Phantom Token pattern hides identity data from external parties, but still allows the API to access the information it needs. The API can validate the token independently and authorize correctly based on the claims.

00:16:48:30 - 00:17:19:37 Another pattern is the HEART token pattern. HEART gets its name from an American healthcare specification that combines OpenID specifications. It includes a token format that is technically a JWT, but it doesn’t contain user-readable identity information.

00:17:19:41 - 00:17:49:02 Instead, the information in the token is mainly about who issued it, not about the user or machine that received it. But this enables routing.

For example, you might have multiple clouds or multiple clusters with different issuers in separate silos. API gateways may only be connected to their own OAuth servers, meaning they can only introspect tokens issued by their own region.

00:17:49:02 - 00:18:07:03 So you might have one gateway connected only to one issuer, and another gateway connected only to another issuer.

00:18:07:07 - 00:18:30:24 Now imagine an application is issued an EU token, meaning the user logged in through the EU region. But the application then calls the US region, maybe because the user clicked a link they shouldn’t have. In a normal situation, the token would be rejected because it wasn’t issued by that region.

00:18:30:33 - 00:18:57:08 But with a HEART token, the API gateway has metadata and can route the request to the correct issuer. The gateway can then decide what to do. Should it reject the request because it’s the wrong region? Or can it route to a copy of the API that serves requests from the correct region?

00:18:57:12 - 00:19:19:34 The HEART token enables routing possibilities. It’s very useful in siloed environments where systems are separated but still owned by the same organization, and where you may need some interoperability.

00:19:19:38 - 00:19:50:35 So in summary: take control of your kill switch. It’s extremely important. If you hand that switch over to a third party, bad things can happen. Even if they don’t, it’s still a major risk, and it’s directly connected to your revenue.

So thank you. And hit me up after if you want to play Pokémon Go.

00:19:50:39 - 00:19:58:21 Go.