SAML, OIDC and RADIUS in Plain English: What Breaks and Where to Look

SAML, OIDC and RADIUS turn up in the same vendor notices, the same change tickets and the same 9am outage. Most support engineers use all three every day without a clean picture of what each one does. This page gives you that picture: what each protocol is for, how a login flows, what breaks, what the user tells you when it does, and which log to open first.

Fun fact: three protocols, three different ideas of what “the server” means. Half the tickets I’ve seen escalated were really one person picturing the wrong server. — Nyx

The one-sentence version

• SAML lets a website trust a login done somewhere else. The identity provider (IdP: Entra ID, Okta, AD FS) signs an XML “assertion” saying who you are, and the browser carries it to the app. Mostly older and enterprise web apps.
• OIDC (OpenID Connect) does the same job for modern web and mobile apps. It is built on OAuth 2.0, and the IdP hands back a signed JSON token (the ID token) instead of XML.
• RADIUS isn’t a web protocol. A network device (VPN gateway, Wi-Fi controller, switch) asks a RADIUS server “should I let this person in?” and gets back Accept, Reject or Challenge. It runs on UDP 1812, with 1813 for accounting.

Who is talking to whom

This is where the confusion starts. In SAML and OIDC, the app and the IdP never talk while the user logs in. The browser carries messages between them. In RADIUS there’s no browser at all: the network device talks straight to the RADIUS server, and the user only ever sees the device.

• SAML: the browser, the app (service provider, SP), and the IdP.
• OIDC: the browser, the app (the “client” or relying party), and the IdP. The app also calls the IdP directly to swap a one-time code for tokens.
• RADIUS: the user’s device, the network device (the RADIUS client), and the RADIUS server (NPS, FreeRADIUS, Cisco ISE, or a cloud RADIUS service).

Yes: in RADIUS the VPN box is the “client”, even though it’s the thing the user connects to. Every new engineer gets this backwards once. — Nyx

1. SAML, as a conversation

Browser to app: “I’d like the payroll site.”

App: “I don’t know you. Take this request to our IdP.” (A redirect carrying a SAML AuthnRequest.)

IdP: “Sign in, and do MFA if policy says so.”

IdP: “Here’s a signed assertion: this is jsmith, valid for the next few minutes, only for the payroll site. Take it back.” (A form the browser posts to the app’s Assertion Consumer Service URL.)

App: checks the signature against the IdP certificate it was given at setup, checks the time window and that the assertion was meant for it, then matches the NameID to a local account. You’re in.

That’s SP-initiated sign-in. IdP-initiated is the same thing started from the IdP’s app portal, without the first request.

What breaks, and what the user says:

• “It worked yesterday, now nobody can get in to that one app.” Usually a signing certificate rollover. The IdP is signing with a new certificate and the app still trusts the old one. One app, every user, starting at the same minute: that pattern points at certificates.
• “It says I’m not allowed / not assigned.” The user isn’t assigned to the app at the IdP. In Entra ID that’s error AADSTS50105.
• “It logged me in as someone else” or “it says my account doesn’t exist.” A NameID or attribute mismatch. The IdP sent an email address, the app expected a username (or the email changed after a name change). Authentication worked; matching the account failed.
• “It works for most people but not for me.” Check the device clock. Assertions are only valid for a short window, and a badly skewed clock on the app server makes valid assertions look expired. Also check group-based assignment and Conditional Access policies that apply only to some users.
• An error straight after setup. The Entity ID or the reply/ACS URL doesn’t match what the IdP has on file. Entra’s version of this is AADSTS50011 (reply address doesn’t match), and AADSTS700016 when it can’t find the application in the tenant at all.

Where to look: the IdP’s sign-in log first (Entra sign-in logs, Okta System Log, or the AD FS Admin event log). If the IdP says “success” but the app still refuses, the problem is on the app side. A browser extension such as SAML-tracer shows the actual assertion going past, so you can read the NameID, the attributes and the time window.

Careful with traces. A captured assertion or token is a live credential until it expires. Don’t paste it into a ticket, a chat or an online decoder. Decode it on your own machine, or strip the signature value before sharing.

2. OIDC, as a conversation

Browser to app: “Log me in.”

App: “Go to the IdP, and tell it I’m client 1234 and to send you back to this exact address.” (A redirect with the client ID, the redirect URI and the scope openid.)

IdP: “Sign in.” Then: “Here’s a one-time code. Take it back to that address.”

App to IdP, directly: “Swap this code for tokens.”

IdP: “Here’s an ID token (who the user is) and an access token (what the app may call on their behalf).”

The ID token is a JWT: three base64 chunks separated by dots, holding the issuer, the audience (the app it was made for), the expiry and the user’s identifiers. Modern apps add PKCE, a one-time secret that stops an intercepted code from being swapped by someone else.

What breaks, and what the user says:

• “It just keeps bouncing back and forth.” A redirect loop. Usually the app can’t keep its own session cookie (blocked third-party cookies, a cookie scoped to the wrong domain, or a load balancer sending each request to a different server) so it keeps asking the IdP again.
• “Error about a redirect URI.” The address the app asked to be sent back to isn’t on the app’s registered list, character for character. A trailing slash or http instead of https is enough. In Entra ID this is the same AADSTS50011.
• “It says I need MFA again” or it asks for MFA from a new place. That’s usually policy doing its job (Entra’s AADSTS50076). Check the sign-in log’s Conditional Access tab before calling it a fault.
• Works in the browser, fails in the mobile app. They are often registered as separate clients with different redirect URIs and consent. Check both registrations.

Where to look: the IdP sign-in log, then the browser’s developer tools (Network tab). The final redirect usually carries an error and error_description in the address, which says plainly what the IdP objected to. The same warning about tokens applies: decode them locally.

3. RADIUS, as a conversation

User to VPN gateway: “jsmith, here’s my password.”

VPN gateway to RADIUS server: an Access-Request, protected with a shared secret that both sides were given at setup.

RADIUS server: checks the password against the directory and runs its policies: which group, which device, what time of day.

RADIUS server: Access-Accept (often with extra attributes, such as which VLAN or VPN group to use), Access-Reject, or Access-Challenge (“ask them for a code”).

The same pattern sits behind enterprise Wi-Fi (802.1X, where EAP runs inside RADIUS) and admin logins to switches and firewalls.

What breaks, and what the user says:

• “I approved the push and the VPN still said it failed.” The classic. When MFA is added to RADIUS, the server waits for the push approval before it answers. If the VPN gateway’s RADIUS timeout is shorter than the time a person takes to find their phone, the gateway gives up first. Raise the timeout on the gateway (vendors that add push MFA to RADIUS commonly recommend around 60 seconds) and check retries aren’t sending a second push.
• “Nobody can connect” after a firewall or IP change. The RADIUS server only answers clients it knows, by IP address and shared secret. A new gateway IP, a changed secret or a blocked UDP 1812 all look the same to the user: a timeout.
• “Wi-Fi won’t connect, but my password is right.” With 802.1X, devices check the RADIUS server’s certificate. An expired or replaced certificate makes managed devices refuse to connect, often all at once.
• “Wrong password” when the password is right. Check for a lockout, or for the request reaching a server that checks a different directory or domain.

Where to look: on Windows NPS, Event Viewer → Custom Views → Server Roles → Network Policy and Access Services (auditing has to be on). Event 6272 means access granted and 6273 means denied, and the reason code in a 6273 tells you why: reason code 16, for example, is a credentials failure. On FreeRADIUS, run the server in debug mode (radiusd -X or freeradius -X) and watch one request go through. If you see nothing at all, the request never arrived: capture on UDP 1812 at the server (see Lab 12) to prove it.

Worth knowing: Blast-RADIUS. RADIUS was designed in the 1990s and protects its replies with MD5. In 2024 researchers showed (CVE-2024-3596) that an attacker sitting between the network device and the RADIUS server could turn a Reject into an Accept. The fixes are to require the Message-Authenticator attribute on every packet, keep RADIUS on a trusted management network, and move to RADIUS over TLS where your products support it. If a vendor notice tells you to “enforce Message-Authenticator”, this is why.

Why a login bug takes everyone down

The part of a gateway that reads SAML messages, the login page itself, works before anyone has signed in. Anyone on the internet can send it a message. So when that code has a memory bug, the first thing that usually happens is that it crashes, and nobody can log in. That’s an availability problem rather than a data leak, and it’s why some SAML advisories read “authentication service repeatedly going offline” (see our NetScaler story).

The scarier kind of SAML bug is in signature checking. If an app can be tricked into accepting an assertion that wasn’t really signed by the IdP (signature-wrapping bugs are the classic family), an attacker can log in as anyone. When you see an advisory, find out which kind it is. A crash bug means “outage risk, patch fast”. A signature bug means “patch, then check sign-in logs for logins that don’t match an IdP sign-in”.

Which one am I looking at?

• Redirects to a Microsoft, Okta or company login page, then lands in an older web app: probably SAML.
• Same, but the app is newer, a mobile app, or anything that says “Sign in with…”: probably OIDC.
• VPN, Wi-Fi, or logging in to a switch or firewall: probably RADIUS (TACACS+ is the other common choice for device admin).
• Not sure? Open the IdP sign-in log for that user and that minute. The protocol is usually listed on the entry.

Interview quick-fire

• Q: One SAML app broke for every user at the same time. First suspect? A: A signing certificate change. Compare the certificate the IdP is signing with against the one the app trusts.
• Q: In SAML, does the app talk to the IdP during login? A: No. The browser carries the request and the signed assertion between them.
• Q: What does OIDC add on top of OAuth 2.0? A: Identity: an ID token that says who signed in. OAuth on its own is about access, not identity.
• Q: User approved the MFA push, VPN still failed. Where do you look? A: The RADIUS timeout on the VPN gateway, then the RADIUS server log for a late Accept.
• Q: On NPS, which events show granted and denied? A: 6272 granted, 6273 denied, with a reason code explaining the denial.

Steven asked me to make this page “short”. It covers three protocols, so this is short. — Nyx

Go deeper

• Modern identity attacks — what attackers do once these logins work: MFA fatigue, token theft, consent phishing
• Lab 12: your first Wireshark capture — prove whether a RADIUS request ever reached the server
• Lab 13: DNS diagnostics — because a surprising number of “SSO is down” tickets are DNS

Original explainer, written from the published protocol designs (SAML 2.0, OpenID Connect Core 1.0, RADIUS RFC 2865) and the vendors’ own documentation for the error codes named (Microsoft Entra ID, Windows NPS). We haven’t tested your tenant or your VPN. If your product behaves differently, tell us and we’ll fix the page.