WEBVTT 1 00:00:00.160 --> 00:00:02.000 Welcome to the deep dive. We're here to help you 2 00:00:02.040 --> 00:00:04.919 get really well informed on some of today's well most 3 00:00:04.919 --> 00:00:09.640 critical topics. And today we're plunging right into the digital 4 00:00:09.679 --> 00:00:14.759 nervous system of our modern world. APIs Application programming interfaces. 5 00:00:14.800 --> 00:00:17.440 I mean they are the invisible glue holding our digital 6 00:00:17.480 --> 00:00:20.280 lives together. Aren't they Your banking app, your smart thermostat, 7 00:00:20.280 --> 00:00:24.399 even websites. APIs are basically the new platforms for business innovation. 8 00:00:24.480 --> 00:00:27.280 They power well almost every digital process you can think of. 9 00:00:27.399 --> 00:00:29.920 Butt and this is a big butt. With this huge 10 00:00:29.960 --> 00:00:34.240 reach comes a critical challenge. Security. It often lags behind 11 00:00:34.280 --> 00:00:38.039 the innovation curve, which makes APIs unfortunately prime targets for 12 00:00:38.560 --> 00:00:40.920 bad actors trying to get their hands on valuable business 13 00:00:40.960 --> 00:00:44.240 data think personal customer info, sensitive IP, you name it. 14 00:00:44.840 --> 00:00:48.200 Securing these digital gateways is just paramount. Imagine the nightmare right, 15 00:00:48.240 --> 00:00:52.759 a single compromised API opening the floodgates. So today we're 16 00:00:52.759 --> 00:00:55.000 going to build a piece by piece that zero trust 17 00:00:55.039 --> 00:00:57.079 fortress you need. Or deep dive today is into cloud 18 00:00:57.159 --> 00:01:00.119 native data security. With OOF, we're drawing directly from the A. 19 00:01:00.200 --> 00:01:03.320 Riley book by Gary Archer, Judith Karr, and because Strosnovski 20 00:01:03.359 --> 00:01:05.719 over at Curity ab Our Mission to give you a 21 00:01:05.760 --> 00:01:08.680 shortcut a way to get truly well informed about securing 22 00:01:08.719 --> 00:01:13.400 modern cloud native apps, especially around authentication and authorization, those 23 00:01:13.439 --> 00:01:14.120 tricky bits. 24 00:01:14.200 --> 00:01:17.760 Yeah, exactly, and the book really hammers home that specifically 25 00:01:17.920 --> 00:01:21.200 two point zero. It's it's more than just a standard protocol, 26 00:01:21.319 --> 00:01:23.519 you know, it's a powerful framework. It gives you the 27 00:01:23.560 --> 00:01:27.599 tools to protect that sensitive data, enforce dynamic access controls. 28 00:01:27.840 --> 00:01:31.680 But just reading this spec isn't enough. True mastery comes 29 00:01:31.680 --> 00:01:35.040 from using it to build a scalable, zero trust architecture. 30 00:01:35.319 --> 00:01:37.400 So then this deep dive, we'll connect the dots right 31 00:01:37.799 --> 00:01:41.400 between digital identity and API security, not just what it is, 32 00:01:41.439 --> 00:01:44.319 but why it matters and crucially, how you actually deploy 33 00:01:44.400 --> 00:01:47.400 these solutions in modern cloud native setups. How you can 34 00:01:48.079 --> 00:01:51.439 externalize that complex security stuff away from your application code 35 00:01:51.680 --> 00:01:54.519 is actually less painful than you might think. It brings 36 00:01:54.519 --> 00:01:55.239 a lot of benefits. 37 00:01:55.400 --> 00:01:58.319 Okay, So to really get why with is so important, though, 38 00:01:58.359 --> 00:02:00.319 maybe let's rewind a bit, take us back back to 39 00:02:00.439 --> 00:02:03.760 say twenty ten. What did API security even look like then? 40 00:02:03.840 --> 00:02:04.879 How limited was it? 41 00:02:05.000 --> 00:02:06.920 Well? Right back then, yeah, it was a different world. 42 00:02:06.920 --> 00:02:09.719 If you were building something digital, it was likely a 43 00:02:09.719 --> 00:02:13.439 single website, mostly talking to a browser client. Users logged 44 00:02:13.479 --> 00:02:16.080 in with a user name of password, and the website 45 00:02:16.120 --> 00:02:21.199 gave them an authentication cookie. Simple, yes, but incredibly limited. 46 00:02:20.879 --> 00:02:23.879 In scope, right, simple but brittle. So contrast that with 47 00:02:23.919 --> 00:02:27.719 today's API first reality. What's the single biggest challenge this 48 00:02:27.800 --> 00:02:30.439 shift created that, like the old cookie model just couldn't 49 00:02:30.439 --> 00:02:30.800 cope with. 50 00:02:31.319 --> 00:02:35.080 It's the sheer distribution and the diversity of clients, that's 51 00:02:35.080 --> 00:02:38.360 the main thing. APIs aren't just internal plumbing anymore. They're 52 00:02:38.400 --> 00:02:41.719 actual business products. They get consumed by mobile apps, by 53 00:02:41.800 --> 00:02:44.960 single page web apps, IoT devices, other back end systems. 54 00:02:45.240 --> 00:02:48.639 The old cookie model it just couldn't scale. It couldn't 55 00:02:48.800 --> 00:02:52.879 authenticate users and authorize access across all those different contexts, 56 00:02:52.879 --> 00:02:57.479 not consistently, not securely. This whole metamorphosis to digital natives, 57 00:02:57.520 --> 00:03:00.560 as the book calls it, it demands something more robust, 58 00:03:00.680 --> 00:03:02.199 more decentralized. 59 00:03:02.280 --> 00:03:04.280 And that's the cue forth two point zero and open 60 00:03:04.280 --> 00:03:07.439 ady connect. Right, they were basically born to solve these 61 00:03:07.479 --> 00:03:09.080 modern complex problems. 62 00:03:09.240 --> 00:03:13.039 Absolutely, they represent a really fundamental shift in how we 63 00:03:13.080 --> 00:03:16.159 think about securing access to valuable data. And oh, with 64 00:03:16.240 --> 00:03:18.800 two point zero it lets us implement this idea of 65 00:03:18.919 --> 00:03:21.960 zero trust security, which isn't just a buzzword. You know, 66 00:03:22.000 --> 00:03:24.560 it's a real shift away from just guarding the perimeter. 67 00:03:24.639 --> 00:03:29.159 It's about pervasive verification. The key insight OTH brings is 68 00:03:29.159 --> 00:03:32.719 how it helps you operationalize zero trust. For APIs, you 69 00:03:32.719 --> 00:03:38.000 could externalize trust decisions, apply consistent authorization even inside your network. 70 00:03:38.280 --> 00:03:41.199 It dismantles that whole flawed idea that inside is safe. 71 00:03:41.479 --> 00:03:45.479 You have to authenticate and authorize every single caller, every request. External, 72 00:03:45.560 --> 00:03:46.560 internal doesn't matter. 73 00:03:46.840 --> 00:03:49.759 Okay, So if the authorization server is the brain, the 74 00:03:49.800 --> 00:03:53.599 central controller, what's the actual currency it deals in? What 75 00:03:53.639 --> 00:03:56.439 does it issue to grant that access? What's at the 76 00:03:56.599 --> 00:03:57.919 very heart of oath. 77 00:03:58.240 --> 00:04:00.159 That would be the access token. You could think of 78 00:04:00.199 --> 00:04:03.240 it as an API message credential. It's basically a powerful 79 00:04:03.240 --> 00:04:06.000 tech string. It carries permissions, It grants access to specific 80 00:04:06.000 --> 00:04:09.039 business data, and crucially this is really important. It must 81 00:04:09.039 --> 00:04:12.639 be designed for least privilege only the absolute minimum access 82 00:04:12.680 --> 00:04:14.719 needed for that specific client to do its job. 83 00:04:15.039 --> 00:04:17.199 Limits the blast radius. If something goes wrong. 84 00:04:17.120 --> 00:04:20.279 Exactly limits the blast radius. And the authorization server is 85 00:04:20.319 --> 00:04:23.639 the component that manages all this. It externalizes most of 86 00:04:23.639 --> 00:04:26.920 that low level security complexity away from your clients, away 87 00:04:26.920 --> 00:04:30.160 from your APIs. It handles authenticating the user if there 88 00:04:30.240 --> 00:04:33.959 is one, and then it issues that access token. Critically, 89 00:04:34.600 --> 00:04:38.240 it keeps the user's credentials, their password or whatever they use, 90 00:04:38.600 --> 00:04:40.399 completely separate from the client application. 91 00:04:40.839 --> 00:04:43.360 Okay, for our listeners who are probably already using some 92 00:04:43.399 --> 00:04:45.839 of this stuff, let's dig into the recommended flows for 93 00:04:45.879 --> 00:04:49.920 getting these tokens. What's something that often gets maybe overlooked 94 00:04:49.959 --> 00:04:53.519 or misunderstood even when people are using best practices, Like 95 00:04:53.639 --> 00:04:54.759 the code flow with PKCE. 96 00:04:55.240 --> 00:04:58.240 Right, the code flow with PKCE, that's PKCE proof key 97 00:04:58.279 --> 00:05:02.680 for code exchange is yeah, the absolute go to for 98 00:05:02.720 --> 00:05:07.160 pretty much any platform specific app dot, web, mobile, desktop. 99 00:05:07.600 --> 00:05:09.839 It's strong because the user logs in directly with the 100 00:05:09.879 --> 00:05:13.120 authorization server. The client app never sees the password that 101 00:05:13.160 --> 00:05:16.560 prevents credential theft by the client itself. But the really 102 00:05:16.639 --> 00:05:20.519 critical insight about PKCE. The code flow seems solid, but 103 00:05:20.600 --> 00:05:26.079 early on people found this subtle but really nasty vulnerability, 104 00:05:26.319 --> 00:05:30.839 authorization code interception, especially on mobile. The genus of pkcees 105 00:05:30.879 --> 00:05:34.040 and just like a checksum, it's this clever cryptographic binding. 106 00:05:34.439 --> 00:05:37.920 It ties the authorization code specifically to the client session 107 00:05:37.959 --> 00:05:41.279 that started the flow that makes the interception attack basically impossible. 108 00:05:41.399 --> 00:05:44.079 So yeah, it's a small addition, but absolutely vital for 109 00:05:44.120 --> 00:05:48.000 securing public clients. Always use PKCE, Always use PKC. 110 00:05:48.319 --> 00:05:50.040 Got it. What about other scenarios? 111 00:05:50.199 --> 00:05:53.800 Well, for devices that don't have easy input, like smart 112 00:05:53.839 --> 00:05:56.959 TVs or maybe some I gadgets, there's the device flow 113 00:05:57.399 --> 00:05:59.959 looks the user authenticate on their phone or laptop instead. 114 00:06:00.319 --> 00:06:02.519 And then for machine to machine communication where there's no 115 00:06:02.600 --> 00:06:05.279 human user involved, like went back end API calling another, 116 00:06:05.720 --> 00:06:09.040 you use the client credentials flow. Important note those access 117 00:06:09.079 --> 00:06:11.519 tokens have no user data in them, They just authorize 118 00:06:11.519 --> 00:06:14.959 the client application itself, and finally you've got the refresh 119 00:06:15.000 --> 00:06:18.319 token flow. This is how clients get fresh access tokens 120 00:06:18.319 --> 00:06:20.920 when the old ones expire, without forcing the user to 121 00:06:20.959 --> 00:06:23.800 log in again and again. The refresh token itself is 122 00:06:23.879 --> 00:06:27.759 usually opaque, kept confidential between the client and the authorization server. 123 00:06:27.920 --> 00:06:32.240 Makes sense, so just as important. What should people actively avoid? 124 00:06:32.360 --> 00:06:37.160 Oh? Definitely number one, avoid the password flow explicitly, don't 125 00:06:37.240 --> 00:06:40.319 use it. It completely breaks the oath model by giving 126 00:06:40.319 --> 00:06:43.639 the client the user's actual password. Big security risk. 127 00:06:43.879 --> 00:06:45.600 Right undermines the whole point. 128 00:06:45.560 --> 00:06:49.000 Exactly, also avoid the implicit flow. It is known security 129 00:06:49.000 --> 00:06:52.560 weaknesses like access tokens potentially ending up in browser history 130 00:06:52.639 --> 00:06:55.879 or server logs because they're in the URL fragment. Both 131 00:06:55.920 --> 00:06:58.199 of these are problematic enough that the upcoming O of 132 00:06:58.240 --> 00:07:01.600 two point one specifications actually moving them entirely. It's all 133 00:07:01.639 --> 00:07:03.560 about consolidating the current best practices. 134 00:07:03.639 --> 00:07:06.040 Okay, so oheth gives us authorization what you can do, 135 00:07:06.399 --> 00:07:08.959 but often you also need to know who is doing it. 136 00:07:09.040 --> 00:07:12.439 How does open id connect or OIDC build on top 137 00:07:12.480 --> 00:07:14.319 of OTH to handle the identity part? 138 00:07:14.439 --> 00:07:16.480 Right, That's a perfect way to put it. OIDC is 139 00:07:16.519 --> 00:07:19.639 an authentication layer built right on top of two point zero. 140 00:07:19.800 --> 00:07:23.560 Oh is about authorization. OIDC is about authentication who you are. 141 00:07:24.120 --> 00:07:27.319 It introduces a new type of token, the ID token. 142 00:07:27.399 --> 00:07:30.160 Now unlike the access token, which really should be treated 143 00:07:30.160 --> 00:07:31.800 as opaque by the client. 144 00:07:31.639 --> 00:07:33.439 Meaning the client shouldn't try to read it. 145 00:07:33.439 --> 00:07:36.480 Exactly, the client shouldn't parse the access token, but the 146 00:07:36.519 --> 00:07:40.480 ID token the client can and should parse it. It 147 00:07:40.519 --> 00:07:44.079 contains information about the user about the authentication event itself. 148 00:07:44.399 --> 00:07:47.319 You get claims like sub that's the user's unique subject 149 00:07:47.360 --> 00:07:50.040 identifier or maybe off time, which tells you when they 150 00:07:50.079 --> 00:07:52.759 last logged in. It's a really crucial distinction. ID token 151 00:07:52.839 --> 00:07:55.680 is for the client, who's the user access token is 152 00:07:55.680 --> 00:07:57.759 for the API. What can this request do? 153 00:07:58.759 --> 00:08:01.399 And I think OIDC also provide something called the user 154 00:08:01.439 --> 00:08:03.800 info endpoint for more profile data. 155 00:08:04.000 --> 00:08:06.600 Yes, that's another way. If the client needs more profile 156 00:08:06.680 --> 00:08:09.240 details about the user beyond what's in the ID token, 157 00:08:09.439 --> 00:08:11.480 it can use the access to open it received to 158 00:08:11.480 --> 00:08:13.720 make a call to the user info endpoint at the 159 00:08:13.759 --> 00:08:16.439 authorization server and fetch that data securely. 160 00:08:16.720 --> 00:08:20.639 Okay, stepping back a bit, you mentioned two point one 161 00:08:20.759 --> 00:08:24.560 consolidating things. Are there other evolutions happening? Oh? 162 00:08:24.680 --> 00:08:27.920 Yeah, the standard space is always moving. Two point one 163 00:08:27.959 --> 00:08:31.120 is about cleaning up and codifying best practices like we discussed. 164 00:08:31.560 --> 00:08:34.639 But looking further out you have emerging things like digital 165 00:08:34.639 --> 00:08:38.279 Credentials protocols or DCP. This is really interesting stuff. It 166 00:08:38.320 --> 00:08:41.759 allows users to manage their own identity attributes, think verifiable 167 00:08:41.799 --> 00:08:45.080 credentials in digital wallets on their devices, and these could 168 00:08:45.120 --> 00:08:48.200 potentially combine with ovos for authentication in the future, giving 169 00:08:48.279 --> 00:08:49.399 users much more control. 170 00:08:49.799 --> 00:08:53.440 Fascinating. So we've got the concepts down oth authorization OIDC 171 00:08:53.600 --> 00:08:57.000 for identity access tokens, different flows. How do these pieces 172 00:08:57.000 --> 00:09:01.039 actually fit together in a modern cloud native architecture? How 173 00:09:01.080 --> 00:09:02.879 do you build that defensive posture. 174 00:09:02.960 --> 00:09:06.600 It's really about separation of concerns, making each component do 175 00:09:06.639 --> 00:09:10.000 its job well. First, you have the authorization server. We've 176 00:09:10.000 --> 00:09:14.919 talked about it. It's the central brain identity management, user authentication, 177 00:09:15.279 --> 00:09:19.840 issuing tokens. It's designed to be adaptable, often extensible. Then 178 00:09:20.039 --> 00:09:22.840 usually have an API gateway. This acts as the front 179 00:09:22.879 --> 00:09:26.080 door to your APIs. It handles things like routing, rate limiting, 180 00:09:26.080 --> 00:09:28.960 maybe some basic checks, but critically it can also perform 181 00:09:29.120 --> 00:09:29.919 token termination. 182 00:09:30.080 --> 00:09:33.279 Token termination. Okay, you mentioned that earlier, the phantom token pattern. 183 00:09:33.320 --> 00:09:36.440 It sounded really clever. Can you unpack how that helps 184 00:09:36.480 --> 00:09:37.320 optimize things? 185 00:09:37.440 --> 00:09:39.960 Yeah, it's a great pattern. So the client application, maybe 186 00:09:40.000 --> 00:09:43.480 a mobile app or SPA, receives an opaque access token, 187 00:09:43.720 --> 00:09:47.919 just a random looking string confidential reveals nothing. The API 188 00:09:48.000 --> 00:09:51.720 gateway gets this opaque token, but instead of just passing 189 00:09:51.720 --> 00:09:55.639 it straight through to the back end API, it introspects it. 190 00:09:56.120 --> 00:09:58.440 That means the gateway makes a quick secure call back 191 00:09:58.440 --> 00:10:01.240 to the authorization server, saying eight is this token valid 192 00:10:01.679 --> 00:10:04.960 and what's inside it? If the authorization server says yep, 193 00:10:05.000 --> 00:10:08.360 it's valid here the permissions and user info. The gateway 194 00:10:08.440 --> 00:10:11.960 then translates that opaque token into a JWT access token. 195 00:10:12.200 --> 00:10:14.240 Ah a json web tooken right. 196 00:10:14.200 --> 00:10:17.200 A self contained sign token, and that JWT is what 197 00:10:17.279 --> 00:10:19.159 gets sent to the upstream API. So you get the 198 00:10:19.159 --> 00:10:23.240 best of both worlds. The client gets confidentiality opaque token, 199 00:10:23.639 --> 00:10:27.519 the internal API gets a verifiable token JWT. It can 200 00:10:27.600 --> 00:10:30.960 validate locally, maybe check the signature, read the claims without 201 00:10:31.000 --> 00:10:34.559 needing another network hop back to the authorization server. Better performance, 202 00:10:34.679 --> 00:10:35.720 better security posture. 203 00:10:35.720 --> 00:10:38.799 Overall, that is clever. Okay, so gateway handles entry and 204 00:10:38.840 --> 00:10:42.759 token translation. What about really fine grained permissions like this 205 00:10:42.879 --> 00:10:45.480 user can view reports but only for their own department. 206 00:10:45.759 --> 00:10:48.759 Good question. That's where a policy engine comes in, often 207 00:10:48.759 --> 00:10:52.559 called an entitlement management system or EMS. This is where 208 00:10:52.600 --> 00:10:56.879 you define and enforce your detailed centralized access control policies 209 00:10:57.279 --> 00:11:01.240 externalize from your application code, which is key for consistency 210 00:11:01.240 --> 00:11:04.639 and manageability. You can implement different models here. Role based 211 00:11:04.639 --> 00:11:09.399 access control r BAC, attribute based access control ABAC, maybe 212 00:11:09.399 --> 00:11:11.799 even relationship based access control REBAC. 213 00:11:12.120 --> 00:11:14.559 Can you give an example of a policy engine? 214 00:11:14.759 --> 00:11:17.360 Sure a popular one in the cloud data space is 215 00:11:17.440 --> 00:11:21.480 Open Policy Agent ORPA. OPA is designed to run as 216 00:11:21.480 --> 00:11:24.720 a sidecar container right alongside your API service. Your API 217 00:11:24.840 --> 00:11:27.200 gets a request with that JWT access token we just 218 00:11:27.200 --> 00:11:29.960 talked about, it can then query its local OPA fied 219 00:11:30.000 --> 00:11:32.639 car hey based on the claims in this token, like 220 00:11:32.879 --> 00:11:35.759 user I, D department rolls, and the policy you have loaded. 221 00:11:36.159 --> 00:11:38.480 Is this user allowed to perform this specific action on 222 00:11:38.519 --> 00:11:41.159 this resource? OPA gives a yes no answer based on 223 00:11:41.159 --> 00:11:43.919 the centralized policy. It's fast, it's local, and it makes 224 00:11:43.960 --> 00:11:47.200 your authorization logic highly auditible and easy to update without 225 00:11:47.240 --> 00:11:50.639 redeploying your main application code. Big win for security agility. 226 00:11:50.759 --> 00:11:54.080 Okay, So summing up the responsibilities, the client gets the 227 00:11:54.120 --> 00:11:57.639 token securely and sends it the API gateway routes maybe 228 00:11:57.679 --> 00:12:01.360 does that phantom token translation, and the back end API 229 00:12:01.759 --> 00:12:04.679 uses the claims in the final token, possibly checking with 230 00:12:04.679 --> 00:12:08.320 a policy engine like OHPA to enforce the really specific 231 00:12:08.440 --> 00:12:09.240 business rules. 232 00:12:09.320 --> 00:12:12.360 Exactly, a nice clean separation of concerns. 233 00:12:12.519 --> 00:12:15.120 Let's zoom back in on the access token itself. You 234 00:12:15.200 --> 00:12:18.919 mentioned jatabts and opaque tokens. This choice seems pretty fundamental 235 00:12:19.039 --> 00:12:22.440 for listeners designing systems. What are the main tradeoffs or 236 00:12:22.440 --> 00:12:26.039 decision points when picking between these formats for different parts 237 00:12:26.039 --> 00:12:26.559 of the flow. 238 00:12:26.919 --> 00:12:30.320 That's a really crucial architectural decision. Yeah, it boils down 239 00:12:30.360 --> 00:12:35.519 to a trade off between performance, verifiability, and confidentiality. So 240 00:12:35.639 --> 00:12:39.399 data bets they are by value tokens self contained. All 241 00:12:39.440 --> 00:12:42.600 the claims are right there inside the token itself protected 242 00:12:42.639 --> 00:12:45.879 by a digital signature. API is often like jatabts because 243 00:12:45.879 --> 00:12:48.799 they can verify the signature locally, check the expiry time, 244 00:12:49.120 --> 00:12:52.360 read the claims, all without calling back to the authorization server. 245 00:12:52.600 --> 00:12:53.440 That's good for performing. 246 00:12:53.440 --> 00:12:54.200 There's always a butt. 247 00:12:54.279 --> 00:12:56.919 The butt is that data bts are typically just signed, 248 00:12:57.200 --> 00:12:59.960 not encrypted, meaning anyone who gets hold of the token 249 00:13:00.080 --> 00:13:03.440 and can decode the payload part and read the claims inside. 250 00:13:03.720 --> 00:13:08.840 If those claims contain sensitive information maybe PII or internal details, 251 00:13:08.879 --> 00:13:11.919 Sending a raw DATABT directly to an untrusted client like 252 00:13:11.919 --> 00:13:15.159 a browser or mobile app can lead to information disclosure. 253 00:13:15.480 --> 00:13:16.039 Not ideal. 254 00:13:16.120 --> 00:13:20.000 Okay, So jata BT's are readable. How do opaque tokens compare? 255 00:13:20.200 --> 00:13:22.919 Opaque tokens are the opposite. They are by reference. They're 256 00:13:22.960 --> 00:13:27.559 just random high entropy strings like a secure section ID. Essentially, 257 00:13:27.559 --> 00:13:29.639 they act as a pointer, a reference back to the 258 00:13:29.639 --> 00:13:32.960 actual token data, which is stored securely on the authorization server, 259 00:13:33.240 --> 00:13:35.840 so they offer optimal confidentiality for the client. The client 260 00:13:35.879 --> 00:13:39.879 gets this random string, it reveals absolutely nothing sensitive if intercepted, 261 00:13:40.159 --> 00:13:42.440 no claims, no user info, nothing readable. 262 00:13:42.559 --> 00:13:44.840 So the choice depends on who receives the token and 263 00:13:44.879 --> 00:13:45.840 what they need to do with it. 264 00:13:46.240 --> 00:13:49.879 Precisely, you typically choose opaque tokens for any public or 265 00:13:49.919 --> 00:13:54.559 browser based clients to maximize confidentiality protect that data. But 266 00:13:54.720 --> 00:13:57.559 for back end server to server communication where the recipient 267 00:13:57.639 --> 00:14:00.720 is trusted and you want the performance benefit of local validation, 268 00:14:01.279 --> 00:14:05.240 a JWT might be perfectly fine, even preferred. And that's 269 00:14:05.240 --> 00:14:08.159 why patterns like the phantom token pattern or another one 270 00:14:08.159 --> 00:14:11.000 called the split token pattern are so valuable. They let 271 00:14:11.039 --> 00:14:14.360 you use opaque tokens externally and JWTs internally. 272 00:14:14.399 --> 00:14:17.679 Breaking that gap makes sense beyond the format, how else 273 00:14:17.720 --> 00:14:20.639 can we harden these access tokens make them even more secure? 274 00:14:21.039 --> 00:14:24.720 Several ways. First, if you are using JWTs, always use 275 00:14:24.720 --> 00:14:28.240 asymmetric signing algorithms like RS two five six or ES 276 00:14:28.320 --> 00:14:31.159 two five six. This means the authorization server signs with 277 00:14:31.200 --> 00:14:34.639 a private key and APIs verify with the corresponding public key, 278 00:14:35.120 --> 00:14:37.600 much better than sharing a symmetric secret key everywhere, which 279 00:14:37.639 --> 00:14:39.320 is harder to manage and rotate securely. 280 00:14:39.399 --> 00:14:41.480 Okay, asymmetric signatures. What else? 281 00:14:41.840 --> 00:14:46.639 Second, look into sender constrained tokens. This is a powerful technique. 282 00:14:46.759 --> 00:14:51.320 Technologies like MTLs, mutual TLS, or dep hot p demonstrating 283 00:14:51.320 --> 00:14:55.240 proof of possession allow you to cryptographically bind the access 284 00:14:55.279 --> 00:14:58.840 token to the specific client instance that requested it. So 285 00:14:58.960 --> 00:15:01.480 even if an attacker some how steals the token itself, 286 00:15:01.799 --> 00:15:04.200 they can't use it unless they also have the client's 287 00:15:04.200 --> 00:15:07.840 private key. It dramatically reduces the value of a stolen token. 288 00:15:07.960 --> 00:15:10.559 Wow. Okay binding the token to the sender. 289 00:15:10.679 --> 00:15:14.399 Yeah. And finally, the basics still apply. Rigorously enforce the 290 00:15:14.440 --> 00:15:17.879 principle of least privilege in the token's permissions, don't grant 291 00:15:17.919 --> 00:15:21.159 more access than absolutely necessary, and you short lived access 292 00:15:21.200 --> 00:15:24.480 tokens keep the expiry time low minutes, not hours or days. 293 00:15:24.799 --> 00:15:27.320 This minimizes the window of opportunity for an attacker if 294 00:15:27.320 --> 00:15:30.120 a token is compromised. Refreshed tokens can handle keeping the 295 00:15:30.200 --> 00:15:32.279 user session a live longer term. 296 00:15:32.399 --> 00:15:35.559 Got it now? You mentioned browser based apps SPA's single 297 00:15:35.559 --> 00:15:38.679 page applications. They have unique challenges right particularly around storing 298 00:15:38.679 --> 00:15:41.840 tokens securely because of things like cross site scripting EXSS. 299 00:15:41.919 --> 00:15:45.120 Oh absolutely, EXSS is a huge headache for spas. If 300 00:15:45.159 --> 00:15:48.759 an attacker can inject malicious JavaScript into your application page 301 00:15:49.159 --> 00:15:52.360 and you're storing your access tokens in somewhere JavaScript can reach, 302 00:15:52.480 --> 00:15:55.799 like local storage or session storage, then that malicious script 303 00:15:55.840 --> 00:15:57.399 can just grab the token and send it off to 304 00:15:57.399 --> 00:15:59.000 the attackers server. Game over. 305 00:15:59.200 --> 00:16:02.240 So storing tokens local storage is a bad idea. 306 00:16:01.919 --> 00:16:06.720 Generally, yes, very risky for spas due to EXSS. The 307 00:16:06.799 --> 00:16:10.000 recommended solution and it's become a pretty standard best practice 308 00:16:10.039 --> 00:16:12.279 now is to use a back end for front end 309 00:16:12.600 --> 00:16:13.960 or BFF. 310 00:16:13.480 --> 00:16:16.559 Pattern BFF back end for frontend. How does that help? 311 00:16:16.679 --> 00:16:21.559 The idea is your SPA doesn't handle the OOTH flow directly. Instead, 312 00:16:21.600 --> 00:16:24.279 you have a lightweight back end service, the BFF that 313 00:16:24.399 --> 00:16:27.600 serves your SPA static files and acts as the OOTH 314 00:16:27.639 --> 00:16:31.039 client itself. So the BFF talks to the authorization server, 315 00:16:31.120 --> 00:16:34.240 gets the access token and refresh token. Then crucially, the 316 00:16:34.320 --> 00:16:37.639 BFF encrypts these tokens and stores them in secure HTTP 317 00:16:37.759 --> 00:16:40.679 only cookies often with the same site strict attribute. 318 00:16:40.279 --> 00:16:43.759 Set HTTP only, meaning JavaScript can't touch them exactly. 319 00:16:44.639 --> 00:16:49.320 Http only cookies are inaccessible to JavaScript running in the browser, 320 00:16:49.960 --> 00:16:53.240 so even if an attacker manages an EXSS injection, they 321 00:16:53.240 --> 00:16:55.200 simply cannot read the tokens out of the cookie jar. 322 00:16:56.039 --> 00:16:59.039 The BFF manages the tokens, attaches them to outgoing API 323 00:16:59.159 --> 00:17:03.720 calls had refresh. The SPA itself never sees or handles 324 00:17:03.720 --> 00:17:07.279 the raw tokens. It dramatically reduces the impact of XSS 325 00:17:07.319 --> 00:17:10.279 on tokens theft, and the same site strict attribute helps 326 00:17:10.319 --> 00:17:13.519 prevent cross set request forgery CSRF two. It's a really 327 00:17:13.519 --> 00:17:15.079 solid pattern for browser security. 328 00:17:15.119 --> 00:17:18.519 Okay, that BFF pattern sounds essential for spas. Let's shift 329 00:17:18.599 --> 00:17:21.039 here slightly. We've talked a lot about the tokens and flows, 330 00:17:21.079 --> 00:17:24.400 but what about managing the authorization server itself? Especially in 331 00:17:24.400 --> 00:17:27.480 a cloud native world. This thing is critical infrastructure, right. 332 00:17:27.519 --> 00:17:29.640 How do you keep it running reliably and manage upgrades 333 00:17:29.640 --> 00:17:30.359 without downtime? 334 00:17:30.640 --> 00:17:33.720 Absolutely critical. You treat it like any other Tier one 335 00:17:33.799 --> 00:17:38.039 service in your cloud environment. Reliability is paramount, so you 336 00:17:38.200 --> 00:17:42.759 leverage standard cloud native patterns first, high availability and clustering. 337 00:17:43.359 --> 00:17:46.559 You don't run just one instance. You run multiple instances, 338 00:17:46.599 --> 00:17:49.559 maybe as pods and Kubernetes, behind a load balancer or 339 00:17:49.599 --> 00:17:52.960 a Kubernetes service to distribute traffic. If one instance fails, 340 00:17:53.119 --> 00:17:53.880 others take. 341 00:17:53.720 --> 00:17:57.079 Over makes sense redundancy. What about bigger failures, like a 342 00:17:57.079 --> 00:17:58.359 whole region going down. 343 00:17:58.640 --> 00:18:02.480 That's where multi region deploys come in. For true disaster recovery, 344 00:18:02.640 --> 00:18:06.599 you run entirely separate, independent deployments of your authorization server 345 00:18:06.880 --> 00:18:09.960 in different geographical regions, maybe US East and US West, 346 00:18:10.119 --> 00:18:13.200 or across continents. You need data replication between them to 347 00:18:13.279 --> 00:18:16.200 keep user sessions and configurations in sync, and then you 348 00:18:16.319 --> 00:18:19.680 use something like Global Server load Balancing GSLB to direct 349 00:18:19.799 --> 00:18:23.039 users to the nearest healthy region with automatic failover if 350 00:18:23.079 --> 00:18:23.799 one region. 351 00:18:23.559 --> 00:18:27.480 Becomes unavailable, okay, high availability, multi region. How do you 352 00:18:27.480 --> 00:18:30.119 actually push out updates or new configurations in this kind 353 00:18:30.160 --> 00:18:32.440 of setup without breaking things carefully? 354 00:18:33.119 --> 00:18:37.519 Through robust deployment pipelines, You package your authorization server as 355 00:18:37.519 --> 00:18:43.039 a container image, You promote that image through standard environments dev, test, staging, 356 00:18:43.160 --> 00:18:47.279 and finally production. In production, you use deployment strategies that 357 00:18:47.319 --> 00:18:51.039 allow for zero downtime upgrades, things like rolling updates blue 358 00:18:51.079 --> 00:18:54.759 green deployments or Canary releases. This lets you gradually introduce 359 00:18:54.759 --> 00:18:58.039 the new version, monitor it, and crucially quickly roll back 360 00:18:58.160 --> 00:18:59.799 or downgrade if any problems show up. 361 00:18:59.839 --> 00:19:01.960 And what about when things do go wrong? How do 362 00:19:02.000 --> 00:19:03.720 you figure out what's happening quickly? 363 00:19:04.000 --> 00:19:08.559 Good point troubleshooting is key. The authorization server needs excellent 364 00:19:08.599 --> 00:19:13.640 observability features. That means providing useful, specific error responses, not 365 00:19:13.680 --> 00:19:17.279 just generic failures. Integrating with distributed tracing systems like open 366 00:19:17.319 --> 00:19:20.440 telemetry is huge. Every request should get a unique trace 367 00:19:20.480 --> 00:19:23.799 ID that flows through the authorization server, the API gateway, 368 00:19:23.960 --> 00:19:25.640 and your back end APIs. 369 00:19:25.319 --> 00:19:27.480 So you can follow a single request across the whole 370 00:19:27.519 --> 00:19:28.599 system exactly. 371 00:19:28.640 --> 00:19:31.920 It makes pinpointing issues much faster. You also need detailed 372 00:19:31.920 --> 00:19:35.400 technical logs for debugging and comprehensive audit logs for security 373 00:19:35.400 --> 00:19:38.759 and compliance purposes. Who logged in, what tokens were issued, 374 00:19:38.960 --> 00:19:43.039 any config changes, and of course good monitoring and alerting 375 00:19:43.039 --> 00:19:46.720 on key metrics to spot potential threads or performance issues early. 376 00:19:47.440 --> 00:19:50.880 Okay, that covers securing access and operating the server. Let's 377 00:19:50.880 --> 00:19:54.200 turn to the very beginning of the flow, the user 378 00:19:54.319 --> 00:19:58.000 proving who they are user authentication. It feels like we've 379 00:19:58.039 --> 00:19:59.759 moved way beyond just passwords. 380 00:19:59.759 --> 00:20:02.720 These oh definitely the landscape there is exploded, which is 381 00:20:02.759 --> 00:20:06.480 great for both security and hopefully user experience. And again, 382 00:20:06.519 --> 00:20:09.279 the beauty of modern flows like the ODC code flow 383 00:20:09.640 --> 00:20:12.880 is that this complexity is largely externalized to the authorization server. 384 00:20:13.079 --> 00:20:16.559 The client application just initiates the flow. The authorization server 385 00:20:16.599 --> 00:20:20.000 then orchestrates whatever authentication method or methods are needed for 386 00:20:20.039 --> 00:20:22.640 that user or context. The client doesn't really need to 387 00:20:22.640 --> 00:20:26.599 know the specifics. The goal is consistency for the APIs downstream. 388 00:20:26.880 --> 00:20:30.319 They should get a reliable, verified subclaim user ID in 389 00:20:30.400 --> 00:20:33.640 the token, regardless of how the user actually proved their identity. 390 00:20:33.759 --> 00:20:35.400 So the API doesn't need to care if I used 391 00:20:35.400 --> 00:20:38.480 a password or my fingerprint or a magic link. As 392 00:20:38.480 --> 00:20:40.839 long as the authorization server vouches for me with a 393 00:20:40.880 --> 00:20:44.920 consistent ID, that is powerful. Let's talk about some of 394 00:20:44.920 --> 00:20:46.440 those methods. What's exciting there. 395 00:20:46.599 --> 00:20:49.640 Well, the big push is towards phishing resistant methods. Top 396 00:20:49.640 --> 00:20:51.960 of the list there is passkeys built on the web. Often, 397 00:20:52.119 --> 00:20:55.720 standard pass keys are a huge leap forward. They're typically 398 00:20:55.720 --> 00:20:59.079 bound to a user's device, often secured by biometrics like 399 00:20:59.119 --> 00:21:02.279 face ID or fingerprint or a device, passing their scope 400 00:21:02.319 --> 00:21:05.920 to specific domains, making them highly resistant to phishing attacks, 401 00:21:06.440 --> 00:21:07.799