Episode 71 — Apply SAML, RADIUS, Kerberos, and OAuth Where Each Fits Best
In this episode, we’re going to take four identity and authentication technologies that students often hear as a confusing jumble of names and turn them into clear, usable ideas that you can place into the right situations. The real skill is not memorizing what each acronym stands for, but understanding what problem each one was built to solve and what assumptions it makes about trust, networks, and users. When you understand the purpose, the fit becomes much easier, and you stop trying to force one technology into every scenario. These four are common because they address different layers of identity: browser-based sign-in, network access, enterprise single sign-on inside a domain, and delegated authorization for modern applications. You will also notice that each one shines in a certain context and becomes awkward or risky if you push it too far beyond that context. The goal here is to help you build mental hooks: what each approach carries, what it does not carry, and what it depends on to be safe and reliable. By the end, you should be able to look at a situation and explain why one of these fits better than the others, without needing to talk about specific vendors or step-by-step setup.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
Before we compare them, it helps to frame the bigger question you are really answering when you choose one of these technologies. You are choosing how identities are proven, how trust is established between systems, and how access decisions can be made without exposing secrets unnecessarily. Some technologies are best at authentication, which is proving who you are, while others are best at authorization, which is proving what you are allowed to do. Some are designed for human users in a browser, while others were designed for devices and network connections. Some rely on a shared environment where systems can talk freely and rely on time synchronization, while others are designed to work across organizations that do not fully trust each other. If you do not ask these underlying questions, you end up picking based on familiarity rather than fit, and that can create security gaps and operational headaches. A practical beginner rule is that identity technologies are like different kinds of keys and passes: a building key, a visitor badge, a parking permit, and a digital token can all relate to access, but they are not interchangeable. When architects “apply” a technology, they are matching it to the trust boundary and the user experience that the system needs. That is why this topic belongs in an architecture course rather than a tool course.
Security Assertion Markup Language (S A M L) is best understood as a way for one system to tell another system, in a trusted and structured way, that a user has authenticated and has certain attributes. It is most commonly used for single sign-on in browser-based enterprise applications, especially when you want users to sign in once to a central identity system and then access many separate services. The central system is called an identity provider, and the applications are called service providers, but the labels matter less than the relationship: one party vouches for the user, and the other party trusts that vouching relationship. S A M L works well when the user experience is a web browser redirect flow, because the browser can carry the necessary messages between the systems without exposing the user’s password to every application. A beginner misunderstanding is thinking S A M L is “an authentication method” like a password, but it is really a federation mechanism, meaning it connects identities across boundaries so applications do not need their own login stores. It is also commonly used when organizations integrate with external services, like a cloud application, and want to keep control of authentication centrally. When you choose S A M L, you are choosing a pattern where identity is asserted and consumed, and you are depending on strong trust configuration and careful handling of assertions.
A useful way to evaluate where S A M L fits best is to focus on what it carries and how it reduces risk. S A M L assertions can carry information about who the user is, whether they authenticated recently, and sometimes what groups or roles they belong to, which allows applications to make access decisions without handling passwords. That reduces the spread of password data and helps centralize controls like Multi-Factor Authentication (M F A), because the identity provider can enforce it and the service providers can rely on it. But S A M L also introduces new risks and constraints: the trust relationship must be configured correctly, certificates must be managed, and time-based validity must be respected so assertions cannot be replayed indefinitely. Another beginner misconception is that S A M L automatically enforces authorization, but the application still has to decide what to do with the attributes it receives. If the application interprets attributes incorrectly, or if the identity provider sends too much data, you can create over-permission. Operationally, S A M L can become fragile if you do not plan for certificate rotation and if you do not define what happens when the identity provider is unavailable. So S A M L fits best when you want browser-based single sign-on, centralized authentication control, and a clean trust boundary between an identity system and many applications, and it fits less well for device-level network access or non-browser application patterns.
Remote Authentication Dial-In User Service (RADIUS) lives in a different world, and that is why it is a common source of confusion when students try to treat it like S A M L. RADIUS is widely used for network access control, meaning it helps decide whether a user or device should be allowed onto a network or allowed to use a network service like wireless access or Virtual Private Network (V P N) access. In this model, there is typically a network access server, like a wireless controller or V P N concentrator, which asks a RADIUS server to validate credentials and return an accept or reject decision along with additional policy information. The important thing to grasp is that the “client” in RADIUS is often a network device, not the end user’s browser, and the system is making decisions about access to network connectivity. RADIUS fits best when you need centralized control over network authentication, because you can enforce consistent rules across many access points without configuring each one independently. A beginner misunderstanding is thinking RADIUS is outdated or only for old dial-up systems, but the concept remains heavily used because the network access problem is still real. When you apply RADIUS, you are choosing a model designed for network devices requesting authentication decisions from a central authority.
RADIUS also highlights an architectural point about where trust lives and what is being protected. In a network access scenario, you care about preventing unauthorized devices and users from joining the network and about applying consistent policy such as which network segment they should be placed in. RADIUS can support decisions like which network profile a user gets, which can translate into segmentation and reduced exposure. It can also support stronger authentication methods by acting as a broker to other identity systems, though the details depend on environment design. The main limitations are that RADIUS is not designed as a rich web federation protocol, and it does not naturally provide the same kind of user attribute assertions for applications. Another architectural constraint is that network access decisions are often time-sensitive, and availability matters; if the RADIUS infrastructure fails, users may lose connectivity. That forces you to design redundancy and define fallback behavior carefully. From a security standpoint, you also need to consider the trust between network devices and the RADIUS server, because if that trust is weak, attackers could spoof requests or responses. The fit is therefore strongest when you need centralized network authentication and policy decisions at the network edge, rather than application-level single sign-on for browser apps.
Kerberos is often the hardest one for beginners at first because it relies on a few concepts that feel abstract until you see the pattern. Kerberos is designed for strong authentication inside an enterprise environment where systems share a trusted domain and can rely on a central authority to issue time-limited tickets. The big idea is that instead of sending passwords around repeatedly, a user authenticates once to a trusted service, receives a ticket, and then presents that ticket to other services to prove identity. That ticket-based approach reduces the exposure of passwords and supports single sign-on within the domain. Kerberos fits best in environments where you control the devices and services, where time synchronization is reliable, and where the network allows the necessary communication with the central ticket authority. A beginner misunderstanding is thinking Kerberos is simply a “Windows thing,” but it is a protocol designed to solve a broader problem: mutual authentication and single sign-on in a controlled environment. Another misunderstanding is thinking Kerberos means “no risk,” but Kerberos tickets can be abused if stolen, and misconfigurations can create security gaps. When you apply Kerberos, you are choosing a design that depends on strong domain trust, careful key management, and stable time and service identity management.
The architectural advantage of Kerberos is that it can provide strong mutual authentication, meaning not only can a server trust a user, but the user can also trust they are talking to the real server. That helps prevent certain impersonation attacks within the enterprise. Kerberos also supports a strong separation between the user’s long-term secret and the tickets used to access services, which reduces repeated secret exposure. However, the constraints are real and matter for fit. Time is a dependency because tickets have lifetimes; if clocks drift, authentication can fail in confusing ways that look like outages. The central ticket service becomes a critical dependency, so resilience and recovery planning must include it. Kerberos also assumes a manageable trust boundary; it is not naturally designed for wide-ranging cross-organization federation in the way S A M L is. So Kerberos fits best for internal enterprise single sign-on where devices and services are within a controlled domain and where you want consistent identity proof across many internal services. When people try to use Kerberos for external-facing consumer sign-in or loosely controlled client devices, they often run into complexity and brittle trust assumptions. That is why an architect applies Kerberos intentionally rather than by habit.
OAuth is the one that many beginners hear in the same breath as S A M L and assume it is another sign-on protocol, which is a very common and understandable confusion. OAuth is primarily an authorization framework, meaning it is about allowing one application to access a resource on behalf of a user without the user giving the application their password. The classic example is letting an application access your profile or your data from another service, but the broader idea is delegated access. Instead of sharing credentials, OAuth issues tokens that represent specific permissions for a limited time and scope. This is incredibly useful in modern application architectures because applications often need to call other services and access user data across boundaries. OAuth fits best when you need a controlled way to delegate access, limit permissions, and support revocation and expiration. A beginner misunderstanding is assuming OAuth authenticates the user by itself, but OAuth focuses on the authorization decision and token issuance for access to resources. Authentication can be layered around OAuth, but the main architectural value is safe delegation. When you apply OAuth, you are choosing a token-based approach that can scale across many services and reduce the spread of passwords.
OAuth brings with it a set of architectural design considerations that matter for fit and safety. Tokens must be protected because they act like keys to access resources, and if a token is stolen, it can be used until it expires or is revoked. That means secure storage on clients, careful handling in transit, and monitoring for misuse. OAuth also pushes you to think about scopes, which are the permissions requested and granted, and beginners often underestimate how important scope design is. If scopes are too broad, tokens become dangerously powerful, and if scopes are too narrow, the system becomes hard to use and integrate. Another consideration is trust relationships between the parties involved, because token issuance requires a trusted authorization server and reliable validation by resource servers. Availability matters too; if token issuance fails, users may not be able to access dependent services, which can cascade. So OAuth fits best when you need delegated access in modern application and A P I ecosystems, where limiting permissions, supporting expiration, and avoiding password sharing are high priorities. It fits less well as a direct replacement for a domain-based ticketing system like Kerberos or a browser-based federation mechanism like S A M L, even though real systems sometimes connect them in broader architectures.
At this point, it helps to compare these four by anchoring them to a few practical questions that architects ask. If you are trying to provide single sign-on to a browser-based enterprise application and you want a central identity provider to assert authentication to many services, S A M L is often the natural fit. If you are trying to control network access for wireless or remote access and you need a central decision point for many network devices, RADIUS is commonly used. If you are inside a managed enterprise domain and you want ticket-based single sign-on with strong mutual authentication across internal services, Kerberos is a strong match. If you are trying to allow applications to access resources on a user’s behalf without sharing the user’s password, and you want token-based delegated authorization with limited scope and lifetime, OAuth fits best. Seeing these as different answers to different questions reduces the urge to treat them as competing brands. Another beginner trap is believing that one of these is always “more secure” than the others, but security depends on correct use and appropriate context. Applying the right one is about aligning trust assumptions with reality. In other words, you choose the right tool for the problem boundary, then you design the surrounding controls to make that tool reliable.
Another important architectural theme is that these technologies are often combined in layered designs, and understanding their boundaries helps you combine them without confusion. For example, a user might authenticate in a browser using S A M L to access an application, and that application might then use OAuth tokens to call downstream services on behalf of the user. Separately, the same user might connect to the enterprise wireless network using RADIUS-backed authentication, and then use Kerberos within the domain to access internal services without re-entering credentials. In each case, the technologies are not duplicates; they are solving different identity problems at different layers. The danger comes when you assume that because a user authenticated successfully at one layer, you no longer need controls at another layer. Network access does not automatically grant application authorization, and application sign-in does not automatically ensure device trust. This layered view is especially important in cloud and hybrid environments, where users and services operate across boundaries and where token-based access is common. When you design the combination, you must ensure consistent identity representation, consistent logging, and clear trust anchors, or else you end up with a system that is hard to audit and easy to misconfigure. For beginners, the key is to see identity as an ecosystem of proofs and permissions, not a single login event.
To close the loop, you should also understand the common failure patterns that happen when these technologies are applied in the wrong place. Using S A M L where there is no browser flow can lead to awkward workarounds that weaken security and user experience. Using RADIUS to try to solve application single sign-on can result in limited context and poor attribute handling, leaving applications to reinvent identity logic. Using Kerberos outside of a controlled domain can create fragile dependencies on time and domain trust that do not hold in the real environment. Using OAuth as if it is just login can cause confusion about what tokens mean and can lead to over-privileged scopes that expand risk. Another failure pattern is forgetting that these systems depend on keys, certificates, and configuration that must be rotated and monitored over time. Certificate expiration and key compromise can cause widespread outages or security incidents, and an architect must plan lifecycle management as part of applying the technology. Finally, misunderstanding the difference between authentication and authorization is a constant source of mistakes, and these four technologies make that distinction very visible. If you remember that authentication proves identity while authorization grants permissions, you will place these technologies more accurately.
Applying S A M L, RADIUS, Kerberos, and OAuth where each fits best is an architectural exercise in matching identity patterns to trust boundaries and usage contexts. S A M L is a strong fit for browser-based federation and enterprise single sign-on where a central identity provider asserts user authentication to many services. RADIUS is a strong fit for centralized network access control where network devices rely on a central authority for authentication and policy decisions. Kerberos is a strong fit for internal enterprise domains that can support ticket-based single sign-on and mutual authentication with stable time and trust. OAuth is a strong fit for delegated authorization in modern application ecosystems where token scope and lifetime limit what access is granted without sharing passwords. When you can explain what problem each one solves, what it depends on, and why it becomes awkward outside its natural home, you gain the real practical skill this certification expects. The deeper lesson is that identity architecture is not about picking the newest or most popular name; it is about building trustworthy flows of proof and permission that remain clear, resilient, and governable as systems scale and evolve.
