Learn Kerberos - Modern Authentication Alternatives

#Introduction

In episode 27, you took Kerberos to the cloud and faced containers, APIs, and an increasingly heterogeneous ecosystem. Within that ecosystem arises a frequently asked question: is Kerberos still relevant, or has it been replaced by OAuth2 and OIDC? Episode 28 answers honestly: it's not about replacing, but about choosing the right tool and making everything work together. Kerberos, OAuth2, OIDC, and SAML have strengths in different domains.

#The Modern Alternatives Map

Before comparing, make sure you understand the four names often mixed up:

Kerberos — a ticket-based network authentication protocol, designed for the enterprise network.
OAuth2 — an authorization framework for granting API access with access tokens.
OIDC (OpenID Connect) — an authentication layer on top of OAuth2 that adds an ID token.
SAML — an XML assertion format for cross-organization SSO, common in enterprise web.

#Kerberos vs OAuth2/OIDC

The basic comparison:

Dimension	Kerberos	OAuth2 / OIDC
Primary function	Authentication plus authorization via tickets	Authorization via tokens; OIDC adds authentication
Credential format	Encrypted binary tickets	Access token / ID token (JWT)
Main clients	Workstations, servers, network applications	Web applications, mobile, APIs
Mechanism	KDC, AS, TGS, tickets and session keys	Authorization server, redirect, token endpoint
Mobile and browser support	Difficult	Designed for it
Lifetime in the enterprise	Decades, still dominant	Increasingly adopted

Kerberos was designed for a world where clients and servers are on the same network and can communicate directly with the KDC. OAuth2 was designed for the internet world, where clients like browsers and mobile devices don't share secret credentials with servers.

#Web vs Enterprise Network

The protocol choice depends on context:

Web and mobile — browsers can't store ticket caches like workstations. OIDC with its redirect flow and tokens in the browser is the natural approach.
Enterprise network — machines joined to the domain, network services like filesystem and printing, and legacy applications are most suited to Kerberos.

Trying to force OIDC across the entire enterprise network is as wrong as forcing Kerberos into public web applications. Both were built for different terrain.

#Mobile and API

Two terrains that clearly belong to OAuth2:

Mobile — applications can't be relied on to store secrets; the OAuth2 flow with PKCE was designed for this situation.
API — cross-service access is expressed as access tokens with scopes, revocable per client, and passable between services without returning to the KDC each time.

Kerberos can still serve internal APIs on the same network, but for public cross-network APIs, access tokens are far more practical.

#Kerberos + SAML: Federation

SAML is a bridge for federation: two organizations (or a realm and the cloud) don't share a KDC, but share trust through an Identity Provider (IdP). The common scenario: an application in one organization accepts logins from users of another organization. SAML lets users do SSO at their home IdP, then send an assertion to a Service Provider (SP).

#SAML Assertions

A SAML assertion carries information about who the user is, when authentication happened, and additional attributes. The assertion is signed by the IdP, so the SP can trust it without sharing a per-user secret.

General form of a SAML assertion

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Subject>budi@example.com</saml:Subject>
    <saml:Conditions NotOnOrAfter="2026-08-03T12:00:00Z"/>
    <saml:AuthnStatement AuthnInstant="2026-08-03T09:00:00Z"/>
</saml:Assertion>

SAML federation and Kerberos complement each other: Kerberos handles authentication inside the network, SAML carries that identity to another organization or service provider.

#Hybrid: Kerberos for Internal, OAuth for External

Modern organizations use both at once. The dividing principle is simple:

Internal — services inside the perimeter use Kerberos; speed, directory integration, and legacy support are the reasons.
External — applications serving the public use OAuth2/OIDC; web and mobile flows run smoothly.

The key to keeping both coherent is mapping identity: Kerberos principals and OIDC accounts must point to the same directory entity, so audit and authorization still use one source of truth.

#Federation Gateway

A federation gateway sits in the middle: it accepts credentials in one protocol and forwards them to another. For example, an internal Kerberos-speaking application is presented to external clients through a gateway that handles OIDC in front and Kerberos behind.

Federation gateway configuration illustration

routes:
  - path: /svc/internal
    authn: kerberos
    upstream: kdc.cluster.local
  - path: /svc/public
    authn: oidc
    issuer: https://idp.example.com
    client_id: public-gateway

Important

A gateway does not replace the security of the protocol itself. It only bridges, and credentials that change hands must still be managed under equally strict rules. Extend audit logging at the gateway — because that's where two different worlds meet.

#Single Sign-On Across Protocols

With the right gateway and identity mapping, users enjoy SSO that crosses protocols: log in once at the IdP, then access Kerberos applications behind it and OAuth2 APIs in front without logging in again. One thing to remember — cross-protocol SSO adds complexity to audit and troubleshooting; you must know at which layer a request fails. Dissecting the flow with KRB5_TRACE on the Kerberos side helps greatly during debugging.

#Migration Strategy

Switching from old to modern authentication doesn't have to hurt. Four steps are commonly used:

Inventory — catalog applications: which speak Kerberos, which are OIDC-ready.
Bridge — let old applications keep using Kerberos, new applications use OIDC.
Federate — connect the realm to the IdP via trust and a gateway.
Replace — legacy applications that have been replaced can be shut down gradually.

#Coexistence Patterns

The most practical coexistence pattern: Kerberos for the internal network and legacy applications; OAuth2/OIDC for APIs, mobile, and public web; SAML for cross-organization federation. Nothing really dies — each fills its own gap.

#Conclusion

Episode 28 placed Kerberos on the modern authentication map. Not obsolete: Kerberos remains the best choice for the enterprise network; OAuth2/OIDC excels at web, mobile, and APIs; SAML is the language of inter-organizational federation. With a federation gateway and good identity mapping, everything can coexist and share SSO.

Key takeaways:

Choose the protocol by battlefield — web and APIs belong to OAuth2/OIDC, the enterprise network to Kerberos.
SAML is a federation bridge, not a KDC replacement.
Hybrid isn't chaos — as long as identity is mapped to one source of truth.
Migration is done gradually, with coexistence, not big-bang.

In the next episode, episode 29, we shift focus from technical to governance: compliance and audit — how to ensure your production Kerberos meets the demands of SOC 2, HIPAA, PCI-DSS, and GDPR, and how to build proper audit logging and access reviews.