Speaker 1: Welcome to the deep dive. We're here to help you
Speaker 1: get really well informed on some of today's well most
Speaker 1: critical topics. And today we're plunging right into the digital
Speaker 1: nervous system of our modern world. APIs Application programming interfaces.
Speaker 1: I mean they are the invisible glue holding our digital
Speaker 1: lives together. Aren't they Your banking app, your smart thermostat,
Speaker 1: even websites. APIs are basically the new platforms for business innovation.
Speaker 1: They power well almost every digital process you can think of.
Speaker 1: Butt and this is a big butt. With this huge
Speaker 1: reach comes a critical challenge. Security. It often lags behind
Speaker 1: the innovation curve, which makes APIs unfortunately prime targets for
Speaker 1: bad actors trying to get their hands on valuable business
Speaker 1: data think personal customer info, sensitive IP, you name it.
Speaker 1: Securing these digital gateways is just paramount. Imagine the nightmare right,
Speaker 1: a single compromised API opening the floodgates. So today we're
Speaker 1: going to build a piece by piece that zero trust
Speaker 1: fortress you need. Or deep dive today is into cloud
Speaker 1: native data security. With OOF, we're drawing directly from the A.
Speaker 1: Riley book by Gary Archer, Judith Karr, and because Strosnovski
Speaker 1: over at Curity ab Our Mission to give you a
Speaker 1: shortcut a way to get truly well informed about securing
Speaker 1: modern cloud native apps, especially around authentication and authorization, those
Speaker 1: tricky bits.
Speaker 2: Yeah, exactly, and the book really hammers home that specifically
Speaker 2: two point zero. It's it's more than just a standard protocol,
Speaker 2: you know, it's a powerful framework. It gives you the
Speaker 2: tools to protect that sensitive data, enforce dynamic access controls.
Speaker 2: But just reading this spec isn't enough. True mastery comes
Speaker 2: from using it to build a scalable, zero trust architecture.
Speaker 2: So then this deep dive, we'll connect the dots right
Speaker 2: between digital identity and API security, not just what it is,
Speaker 2: but why it matters and crucially, how you actually deploy
Speaker 2: these solutions in modern cloud native setups. How you can
Speaker 2: externalize that complex security stuff away from your application code
Speaker 2: is actually less painful than you might think. It brings
Speaker 2: a lot of benefits.
Speaker 1: Okay, So to really get why with is so important, though,
Speaker 1: maybe let's rewind a bit, take us back back to
Speaker 1: say twenty ten. What did API security even look like then?
Speaker 1: How limited was it?
Speaker 2: Well? Right back then, yeah, it was a different world.
Speaker 2: If you were building something digital, it was likely a
Speaker 2: single website, mostly talking to a browser client. Users logged
Speaker 2: in with a user name of password, and the website
Speaker 2: gave them an authentication cookie. Simple, yes, but incredibly limited.
Speaker 1: In scope, right, simple but brittle. So contrast that with
Speaker 1: today's API first reality. What's the single biggest challenge this
Speaker 1: shift created that, like the old cookie model just couldn't
Speaker 1: cope with.
Speaker 2: It's the sheer distribution and the diversity of clients, that's
Speaker 2: the main thing. APIs aren't just internal plumbing anymore. They're
Speaker 2: actual business products. They get consumed by mobile apps, by
Speaker 2: single page web apps, IoT devices, other back end systems.
Speaker 2: The old cookie model it just couldn't scale. It couldn't
Speaker 2: authenticate users and authorize access across all those different contexts,
Speaker 2: not consistently, not securely. This whole metamorphosis to digital natives,
Speaker 2: as the book calls it, it demands something more robust,
Speaker 2: more decentralized.
Speaker 1: And that's the cue forth two point zero and open
Speaker 1: ady connect. Right, they were basically born to solve these
Speaker 1: modern complex problems.
Speaker 2: Absolutely, they represent a really fundamental shift in how we
Speaker 2: think about securing access to valuable data. And oh, with
Speaker 2: two point zero it lets us implement this idea of
Speaker 2: zero trust security, which isn't just a buzzword. You know,
Speaker 2: it's a real shift away from just guarding the perimeter.
Speaker 2: It's about pervasive verification. The key insight OTH brings is
Speaker 2: how it helps you operationalize zero trust. For APIs, you
Speaker 2: could externalize trust decisions, apply consistent authorization even inside your network.
Speaker 2: It dismantles that whole flawed idea that inside is safe.
Speaker 2: You have to authenticate and authorize every single caller, every request. External,
Speaker 2: internal doesn't matter.
Speaker 1: Okay, So if the authorization server is the brain, the
Speaker 1: central controller, what's the actual currency it deals in? What
Speaker 1: does it issue to grant that access? What's at the
Speaker 1: very heart of oath.
Speaker 2: That would be the access token. You could think of
Speaker 2: it as an API message credential. It's basically a powerful
Speaker 2: tech string. It carries permissions, It grants access to specific
Speaker 2: business data, and crucially this is really important. It must
Speaker 2: be designed for least privilege only the absolute minimum access
Speaker 2: needed for that specific client to do its job.
Speaker 1: Limits the blast radius. If something goes wrong.
Speaker 2: Exactly limits the blast radius. And the authorization server is
Speaker 2: the component that manages all this. It externalizes most of
Speaker 2: that low level security complexity away from your clients, away
Speaker 2: from your APIs. It handles authenticating the user if there
Speaker 2: is one, and then it issues that access token. Critically,
Speaker 2: it keeps the user's credentials, their password or whatever they use,
Speaker 2: completely separate from the client application.
Speaker 1: Okay, for our listeners who are probably already using some
Speaker 1: of this stuff, let's dig into the recommended flows for
Speaker 1: getting these tokens. What's something that often gets maybe overlooked
Speaker 1: or misunderstood even when people are using best practices, Like
Speaker 1: the code flow with PKCE.
Speaker 2: Right, the code flow with PKCE, that's PKCE proof key
Speaker 2: for code exchange is yeah, the absolute go to for
Speaker 2: pretty much any platform specific app dot, web, mobile, desktop.
Speaker 2: It's strong because the user logs in directly with the
Speaker 2: authorization server. The client app never sees the password that
Speaker 2: prevents credential theft by the client itself. But the really
Speaker 2: critical insight about PKCE. The code flow seems solid, but
Speaker 2: early on people found this subtle but really nasty vulnerability,
Speaker 2: authorization code interception, especially on mobile. The genus of pkcees
Speaker 2: and just like a checksum, it's this clever cryptographic binding.
Speaker 2: It ties the authorization code specifically to the client session
Speaker 2: that started the flow that makes the interception attack basically impossible.
Speaker 2: So yeah, it's a small addition, but absolutely vital for
Speaker 2: securing public clients. Always use PKCE, Always use PKC.
Speaker 1: Got it. What about other scenarios?
Speaker 2: Well, for devices that don't have easy input, like smart
Speaker 2: TVs or maybe some I gadgets, there's the device flow
Speaker 2: looks the user authenticate on their phone or laptop instead.
Speaker 2: And then for machine to machine communication where there's no
Speaker 2: human user involved, like went back end API calling another,
Speaker 2: you use the client credentials flow. Important note those access
Speaker 2: tokens have no user data in them, They just authorize
Speaker 2: the client application itself, and finally you've got the refresh
Speaker 2: token flow. This is how clients get fresh access tokens
Speaker 2: when the old ones expire, without forcing the user to
Speaker 2: log in again and again. The refresh token itself is
Speaker 2: usually opaque, kept confidential between the client and the authorization server.
Speaker 1: Makes sense, so just as important. What should people actively avoid?
Speaker 2: Oh? Definitely number one, avoid the password flow explicitly, don't
Speaker 2: use it. It completely breaks the oath model by giving
Speaker 2: the client the user's actual password. Big security risk.
Speaker 1: Right undermines the whole point.
Speaker 2: Exactly, also avoid the implicit flow. It is known security
Speaker 2: weaknesses like access tokens potentially ending up in browser history
Speaker 2: or server logs because they're in the URL fragment. Both
Speaker 2: of these are problematic enough that the upcoming O of
Speaker 2: two point one specifications actually moving them entirely. It's all
Speaker 2: about consolidating the current best practices.
Speaker 1: Okay, so oheth gives us authorization what you can do,
Speaker 1: but often you also need to know who is doing it.
Speaker 1: How does open id connect or OIDC build on top
Speaker 1: of OTH to handle the identity part?
Speaker 2: Right, That's a perfect way to put it. OIDC is
Speaker 2: an authentication layer built right on top of two point zero.
Speaker 2: Oh is about authorization. OIDC is about authentication who you are.
Speaker 2: It introduces a new type of token, the ID token.
Speaker 2: Now unlike the access token, which really should be treated
Speaker 2: as opaque by the client.
Speaker 1: Meaning the client shouldn't try to read it.
Speaker 2: Exactly, the client shouldn't parse the access token, but the
Speaker 2: ID token the client can and should parse it. It
Speaker 2: contains information about the user about the authentication event itself.
Speaker 2: You get claims like sub that's the user's unique subject
Speaker 2: identifier or maybe off time, which tells you when they
Speaker 2: last logged in. It's a really crucial distinction. ID token
Speaker 2: is for the client, who's the user access token is
Speaker 2: for the API. What can this request do?
Speaker 1: And I think OIDC also provide something called the user
Speaker 1: info endpoint for more profile data.
Speaker 2: Yes, that's another way. If the client needs more profile
Speaker 2: details about the user beyond what's in the ID token,
Speaker 2: it can use the access to open it received to
Speaker 2: make a call to the user info endpoint at the
Speaker 2: authorization server and fetch that data securely.
Speaker 1: Okay, stepping back a bit, you mentioned two point one
Speaker 1: consolidating things. Are there other evolutions happening? Oh?
Speaker 2: Yeah, the standard space is always moving. Two point one
Speaker 2: is about cleaning up and codifying best practices like we discussed.
Speaker 2: But looking further out you have emerging things like digital
Speaker 2: Credentials protocols or DCP. This is really interesting stuff. It
Speaker 2: allows users to manage their own identity attributes, think verifiable
Speaker 2: credentials in digital wallets on their devices, and these could
Speaker 2: potentially combine with ovos for authentication in the future, giving
Speaker 2: users much more control.
Speaker 1: Fascinating. So we've got the concepts down oth authorization OIDC
Speaker 1: for identity access tokens, different flows. How do these pieces
Speaker 1: actually fit together in a modern cloud native architecture? How
Speaker 1: do you build that defensive posture.
Speaker 2: It's really about separation of concerns, making each component do
Speaker 2: its job well. First, you have the authorization server. We've
Speaker 2: talked about it. It's the central brain identity management, user authentication,
Speaker 2: issuing tokens. It's designed to be adaptable, often extensible. Then
Speaker 2: usually have an API gateway. This acts as the front
Speaker 2: door to your APIs. It handles things like routing, rate limiting,
Speaker 2: maybe some basic checks, but critically it can also perform
Speaker 2: token termination.
Speaker 1: Token termination. Okay, you mentioned that earlier, the phantom token pattern.
Speaker 1: It sounded really clever. Can you unpack how that helps
Speaker 1: optimize things?
Speaker 2: Yeah, it's a great pattern. So the client application, maybe
Speaker 2: a mobile app or SPA, receives an opaque access token,
Speaker 2: just a random looking string confidential reveals nothing. The API
Speaker 2: gateway gets this opaque token, but instead of just passing
Speaker 2: it straight through to the back end API, it introspects it.
Speaker 2: That means the gateway makes a quick secure call back
Speaker 2: to the authorization server, saying eight is this token valid
Speaker 2: and what's inside it? If the authorization server says yep,
Speaker 2: it's valid here the permissions and user info. The gateway
Speaker 2: then translates that opaque token into a JWT access token.
Speaker 1: Ah a json web tooken right.
Speaker 2: A self contained sign token, and that JWT is what
Speaker 2: gets sent to the upstream API. So you get the
Speaker 2: best of both worlds. The client gets confidentiality opaque token,
Speaker 2: the internal API gets a verifiable token JWT. It can
Speaker 2: validate locally, maybe check the signature, read the claims without
Speaker 2: needing another network hop back to the authorization server. Better performance,
Speaker 2: better security posture.
Speaker 1: Overall, that is clever. Okay, so gateway handles entry and
Speaker 1: token translation. What about really fine grained permissions like this
Speaker 1: user can view reports but only for their own department.
Speaker 2: Good question. That's where a policy engine comes in, often
Speaker 2: called an entitlement management system or EMS. This is where
Speaker 2: you define and enforce your detailed centralized access control policies
Speaker 2: externalize from your application code, which is key for consistency
Speaker 2: and manageability. You can implement different models here. Role based
Speaker 2: access control r BAC, attribute based access control ABAC, maybe
Speaker 2: even relationship based access control REBAC.
Speaker 1: Can you give an example of a policy engine?
Speaker 2: Sure a popular one in the cloud data space is
Speaker 2: Open Policy Agent ORPA. OPA is designed to run as
Speaker 2: a sidecar container right alongside your API service. Your API
Speaker 2: gets a request with that JWT access token we just
Speaker 2: talked about, it can then query its local OPA fied
Speaker 2: car hey based on the claims in this token, like
Speaker 2: user I, D department rolls, and the policy you have loaded.
Speaker 2: Is this user allowed to perform this specific action on
Speaker 2: this resource? OPA gives a yes no answer based on
Speaker 2: the centralized policy. It's fast, it's local, and it makes
Speaker 2: your authorization logic highly auditible and easy to update without
Speaker 2: redeploying your main application code. Big win for security agility.
Speaker 1: Okay, So summing up the responsibilities, the client gets the
Speaker 1: token securely and sends it the API gateway routes maybe
Speaker 1: does that phantom token translation, and the back end API
Speaker 1: uses the claims in the final token, possibly checking with
Speaker 1: a policy engine like OHPA to enforce the really specific
Speaker 1: business rules.
Speaker 2: Exactly, a nice clean separation of concerns.
Speaker 1: Let's zoom back in on the access token itself. You
Speaker 1: mentioned jatabts and opaque tokens. This choice seems pretty fundamental
Speaker 1: for listeners designing systems. What are the main tradeoffs or
Speaker 1: decision points when picking between these formats for different parts
Speaker 1: of the flow.
Speaker 2: That's a really crucial architectural decision. Yeah, it boils down
Speaker 2: to a trade off between performance, verifiability, and confidentiality. So
Speaker 2: data bets they are by value tokens self contained. All
Speaker 2: the claims are right there inside the token itself protected
Speaker 2: by a digital signature. API is often like jatabts because
Speaker 2: they can verify the signature locally, check the expiry time,
Speaker 2: read the claims, all without calling back to the authorization server.
Speaker 2: That's good for performing.
Speaker 1: There's always a butt.
Speaker 2: The butt is that data bts are typically just signed,
Speaker 2: not encrypted, meaning anyone who gets hold of the token
Speaker 2: and can decode the payload part and read the claims inside.
Speaker 2: If those claims contain sensitive information maybe PII or internal details,
Speaker 2: Sending a raw DATABT directly to an untrusted client like
Speaker 2: a browser or mobile app can lead to information disclosure.
Speaker 2: Not ideal.
Speaker 1: Okay, So jata BT's are readable. How do opaque tokens compare?
Speaker 2: Opaque tokens are the opposite. They are by reference. They're
Speaker 2: just random high entropy strings like a secure section ID. Essentially,
Speaker 2: they act as a pointer, a reference back to the
Speaker 2: actual token data, which is stored securely on the authorization server,
Speaker 2: so they offer optimal confidentiality for the client. The client
Speaker 2: gets this random string, it reveals absolutely nothing sensitive if intercepted,
Speaker 2: no claims, no user info, nothing readable.
Speaker 1: So the choice depends on who receives the token and
Speaker 1: what they need to do with it.
Speaker 2: Precisely, you typically choose opaque tokens for any public or
Speaker 2: browser based clients to maximize confidentiality protect that data. But
Speaker 2: for back end server to server communication where the recipient
Speaker 2: is trusted and you want the performance benefit of local validation,
Speaker 2: a JWT might be perfectly fine, even preferred. And that's
Speaker 2: why patterns like the phantom token pattern or another one
Speaker 2: called the split token pattern are so valuable. They let
Speaker 2: you use opaque tokens externally and JWTs internally.
Speaker 1: Breaking that gap makes sense beyond the format, how else
Speaker 1: can we harden these access tokens make them even more secure?
Speaker 2: Several ways. First, if you are using JWTs, always use
Speaker 2: asymmetric signing algorithms like RS two five six or ES
Speaker 2: two five six. This means the authorization server signs with
Speaker 2: a private key and APIs verify with the corresponding public key,
Speaker 2: much better than sharing a symmetric secret key everywhere, which
Speaker 2: is harder to manage and rotate securely.
Speaker 1: Okay, asymmetric signatures. What else?
Speaker 2: Second, look into sender constrained tokens. This is a powerful technique.
Speaker 2: Technologies like MTLs, mutual TLS, or dep hot p demonstrating
Speaker 2: proof of possession allow you to cryptographically bind the access
Speaker 2: token to the specific client instance that requested it. So
Speaker 2: even if an attacker some how steals the token itself,
Speaker 2: they can't use it unless they also have the client's
Speaker 2: private key. It dramatically reduces the value of a stolen token.
Speaker 1: Wow. Okay binding the token to the sender.
Speaker 2: Yeah. And finally, the basics still apply. Rigorously enforce the
Speaker 2: principle of least privilege in the token's permissions, don't grant
Speaker 2: more access than absolutely necessary, and you short lived access
Speaker 2: tokens keep the expiry time low minutes, not hours or days.
Speaker 2: This minimizes the window of opportunity for an attacker if
Speaker 2: a token is compromised. Refreshed tokens can handle keeping the
Speaker 2: user session a live longer term.
Speaker 1: Got it now? You mentioned browser based apps SPA's single
Speaker 1: page applications. They have unique challenges right particularly around storing
Speaker 1: tokens securely because of things like cross site scripting EXSS.
Speaker 2: Oh absolutely, EXSS is a huge headache for spas. If
Speaker 2: an attacker can inject malicious JavaScript into your application page
Speaker 2: and you're storing your access tokens in somewhere JavaScript can reach,
Speaker 2: like local storage or session storage, then that malicious script
Speaker 2: can just grab the token and send it off to
Speaker 2: the attackers server. Game over.
Speaker 1: So storing tokens local storage is a bad idea.
Speaker 2: Generally, yes, very risky for spas due to EXSS. The
Speaker 2: recommended solution and it's become a pretty standard best practice
Speaker 2: now is to use a back end for front end
Speaker 2: or BFF.
Speaker 1: Pattern BFF back end for frontend. How does that help?
Speaker 2: The idea is your SPA doesn't handle the OOTH flow directly. Instead,
Speaker 2: you have a lightweight back end service, the BFF that
Speaker 2: serves your SPA static files and acts as the OOTH
Speaker 2: client itself. So the BFF talks to the authorization server,
Speaker 2: gets the access token and refresh token. Then crucially, the
Speaker 2: BFF encrypts these tokens and stores them in secure HTTP
Speaker 2: only cookies often with the same site strict attribute.
Speaker 1: Set HTTP only, meaning JavaScript can't touch them exactly.
Speaker 2: Http only cookies are inaccessible to JavaScript running in the browser,
Speaker 2: so even if an attacker manages an EXSS injection, they
Speaker 2: simply cannot read the tokens out of the cookie jar.
Speaker 2: The BFF manages the tokens, attaches them to outgoing API
Speaker 2: calls had refresh. The SPA itself never sees or handles
Speaker 2: the raw tokens. It dramatically reduces the impact of XSS
Speaker 2: on tokens theft, and the same site strict attribute helps
Speaker 2: prevent cross set request forgery CSRF two. It's a really
Speaker 2: solid pattern for browser security.
Speaker 1: Okay, that BFF pattern sounds essential for spas. Let's shift
Speaker 1: here slightly. We've talked a lot about the tokens and flows,
Speaker 1: but what about managing the authorization server itself? Especially in
Speaker 1: a cloud native world. This thing is critical infrastructure, right.
Speaker 1: How do you keep it running reliably and manage upgrades
Speaker 1: without downtime?
Speaker 2: Absolutely critical. You treat it like any other Tier one
Speaker 2: service in your cloud environment. Reliability is paramount, so you
Speaker 2: leverage standard cloud native patterns first, high availability and clustering.
Speaker 2: You don't run just one instance. You run multiple instances,
Speaker 2: maybe as pods and Kubernetes, behind a load balancer or
Speaker 2: a Kubernetes service to distribute traffic. If one instance fails,
Speaker 2: others take.
Speaker 1: Over makes sense redundancy. What about bigger failures, like a
Speaker 1: whole region going down.
Speaker 2: That's where multi region deploys come in. For true disaster recovery,
Speaker 2: you run entirely separate, independent deployments of your authorization server
Speaker 2: in different geographical regions, maybe US East and US West,
Speaker 2: or across continents. You need data replication between them to
Speaker 2: keep user sessions and configurations in sync, and then you
Speaker 2: use something like Global Server load Balancing GSLB to direct
Speaker 2: users to the nearest healthy region with automatic failover if
Speaker 2: one region.
Speaker 1: Becomes unavailable, okay, high availability, multi region. How do you
Speaker 1: actually push out updates or new configurations in this kind
Speaker 1: of setup without breaking things carefully?
Speaker 2: Through robust deployment pipelines, You package your authorization server as
Speaker 2: a container image, You promote that image through standard environments dev, test, staging,
Speaker 2: and finally production. In production, you use deployment strategies that
Speaker 2: allow for zero downtime upgrades, things like rolling updates blue
Speaker 2: green deployments or Canary releases. This lets you gradually introduce
Speaker 2: the new version, monitor it, and crucially quickly roll back
Speaker 2: or downgrade if any problems show up.
Speaker 1: And what about when things do go wrong? How do
Speaker 1: you figure out what's happening quickly?
Speaker 2: Good point troubleshooting is key. The authorization server needs excellent
Speaker 2: observability features. That means providing useful, specific error responses, not
Speaker 2: just generic failures. Integrating with distributed tracing systems like open
Speaker 2: telemetry is huge. Every request should get a unique trace
Speaker 2: ID that flows through the authorization server, the API gateway,
Speaker 2: and your back end APIs.
Speaker 1: So you can follow a single request across the whole
Speaker 1: system exactly.
Speaker 2: It makes pinpointing issues much faster. You also need detailed
Speaker 2: technical logs for debugging and comprehensive audit logs for security
Speaker 2: and compliance purposes. Who logged in, what tokens were issued,
Speaker 2: any config changes, and of course good monitoring and alerting
Speaker 2: on key metrics to spot potential threads or performance issues early.
Speaker 1: Okay, that covers securing access and operating the server. Let's
Speaker 1: turn to the very beginning of the flow, the user
Speaker 1: proving who they are user authentication. It feels like we've
Speaker 1: moved way beyond just passwords.
Speaker 2: These oh definitely the landscape there is exploded, which is
Speaker 2: great for both security and hopefully user experience. And again,
Speaker 2: the beauty of modern flows like the ODC code flow
Speaker 2: is that this complexity is largely externalized to the authorization server.
Speaker 2: The client application just initiates the flow. The authorization server
Speaker 2: then orchestrates whatever authentication method or methods are needed for
Speaker 2: that user or context. The client doesn't really need to
Speaker 2: know the specifics. The goal is consistency for the APIs downstream.
Speaker 2: They should get a reliable, verified subclaim user ID in
Speaker 2: the token, regardless of how the user actually proved their identity.
Speaker 1: So the API doesn't need to care if I used
Speaker 1: a password or my fingerprint or a magic link. As
Speaker 1: long as the authorization server vouches for me with a
Speaker 1: consistent ID, that is powerful. Let's talk about some of
Speaker 1: those methods. What's exciting there.
Speaker 2: Well, the big push is towards phishing resistant methods. Top
Speaker 2: of the list there is passkeys built on the web. Often,
Speaker 2: standard pass keys are a huge leap forward. They're typically
Speaker 2: bound to a user's device, often secured by biometrics like
Speaker 2: face ID or fingerprint or a device, passing their scope
Speaker 2: to specific domains, making them highly resistant to phishing attacks,
Speaker 2: much much better than passwords.
Speaker 1: Okay, pass keys are the gold standard. What else is common?
Speaker 2: You still see one time passwords OTP quite a bit
Speaker 2: delivered via email, SMS or generated biauthenticator apps. They're better
Speaker 2: than just a password, but generally not considered phishing resistant.
Speaker 2: Social logins or using external identity providers like login with
Speaker 2: Google or log in with Azure D are popular for convenience,
Speaker 2: though you need to manage things like mapping those external
Speaker 2: identities to your internal user accounts. For scenarios requiring higher
Speaker 2: assurance about the user's real world identity, you get into
Speaker 2: identity proofing processes, and as we mentioned, digital credentials protocols
Speaker 2: DCP are emerging here, allowing users to present verified attributes,
Speaker 2: and most good authorization servers are extensible, allowing you to
Speaker 2: plug in custom user authentication methods. If you need to
Speaker 2: integrate with, say a legacy database or a very specific
Speaker 2: internal system, that's.
Speaker 1: A lot of options. Are there also techniques for combining
Speaker 1: these or making the experience smarter?
Speaker 2: Yes, absolutely, Several key user authentication techniques layer on top
Speaker 2: of the methods Multi factor authentication MFA is probably the
Speaker 2: most well known. Combining two or more different types of factors.
Speaker 2: Something you know, password, something you have OTP device, phone,
Speaker 2: something you are biometric provides much stronger security than any
Speaker 2: single factor alone.
Speaker 1: Right, MFA is crucial.
Speaker 2: Then there's step up authentication. This is a really neat
Speaker 2: dynamic technique. Instead of forcing high security on the user
Speaker 2: all the time, you might let them log in with
Speaker 2: something simple initially, but if they try to access a
Speaker 2: particularly sensitive resource or perform a high privilege operation, the
Speaker 2: API can signal back to the authorization server, Hey, I
Speaker 2: need stronger proof for this user. The authorization server can
Speaker 2: then trigger an MFA challenge, maybe ask for a pass
Speaker 2: key verification just for that sensitive step. It balances security
Speaker 2: and user experience nicely.
Speaker 1: Clever friction only one needed exactly.
Speaker 2: You also have single sign on SSO, which aims to
Speaker 2: reduce how often users need to log in across different applications.
Speaker 2: Account linking helps manage identities when users authenticate via multiple
Speaker 2: external providers, and advanced systems allow authentication actions and selection
Speaker 2: logic basically custom rules to decide which authentication methods to
Speaker 2: offer or require based on user type, location, device posture,
Speaker 2: risk score or other contextual factors tailoring the experience.
Speaker 1: And all of this from the first time a user
Speaker 1: signs up, maybe self service through password resets or account recovery,
Speaker 1: all the way to eventually decommissioning their account. That whole
Speaker 1: life cycle is managed by the authorization server.
Speaker 2: That's the goal. Yes, Centralizing that entire user authentication life
Speaker 2: cycle management within the authorization server provides consistency, security, and auditability.
Speaker 1: Wow, Okay, what an incredible journey we've been on. We
Speaker 1: started with why we even need something like go out
Speaker 1: in this API driven world. We dug into the core
Speaker 1: bits like access token and flows PKCE. Then we looked
Speaker 1: at the architecture of the authorization server API gateway policy
Speaker 1: engines that cool phantom token pattern. We talked JWT's versus
Speaker 1: opaque hardening tokens, protecting spas with BFFs, dot covered, operating
Speaker 1: the authorization server reliably in the cloud, and finally explore
Speaker 1: the whole universe of modern user authentication beyond passwords. That
Speaker 1: was a lot.
Speaker 2: It really ties together though a well designed ooth and
Speaker 2: open ID connect implementation when you combine it with these
Speaker 2: cloud native patterns like gateways policy engines and reliable operations.
Speaker 2: It truly enables a powerful, scalable and secures zero trust architecture.
Speaker 2: The core themes are externalizing that complex security logic, rigorously
Speaker 2: applying these privilege staying adaptable with things like step up OFF,
Speaker 2: and just generally keeping pace with both the evolving threats
Speaker 2: and what users expect in terms of experience.
Speaker 1: So for everyone listening, as you continue to build and
Speaker 1: innovate in this digital world, really consider how adopting these standards,
Speaker 1: creating what the book calls an unforgeable least privilege API
Speaker 1: message credential, how that can fundamentally transform the trust and
Speaker 1: the security posture around your business data, your user interactions.
Speaker 1: What new possibilities does having this kind of robust, scalable
Speaker 1: security foundation actually unlock for your next big digital initiative.
Speaker 1: Something to think about,