What category of protocol this is
Kerberos is a network authentication protocol. The core specification is RFC 4120, published in July 2005. The official title is The Kerberos Network Authentication Service (Version 5). RFC 4120 obsoletes RFC 1510, the earlier Version 5 specification. RFC 4120 is an IETF standards-track document. Kerberos is not a U.S. statute, not a federal program, and not a product.
The core idea is a trusted third party. Clients obtain tickets from a Key Distribution Center (KDC). With those tickets, a client and a service can authenticate without a long-term secret on the wire to every service. A password-derived key is one example of a long-term secret. RFC 4120 assumes an open network where packets can be read, modified, and inserted. That assumption is why tickets are encrypted and paired with session keys. Users and services are principals. Each principal belongs to a realm. A realm is the administrative domain that a KDC serves.
Edition covered
The edition is Kerberos Version 5 as specified in RFC 4120 (July 2005). Later RFCs update parts of Version 5, such as encryption types and extensions. The Updated by list on the RFC Editor page for RFC 4120 names those later RFCs.
NIST SP 800-57 Part 3 Revision 1 is an optional vocabulary companion. Its official title is Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance. That publication includes a high-level Kerberos overview.
Four actors on one screen
The client is the principal that asks to use something, such as the workstation of a user. The Authentication Service (AS) is the KDC entry point for the first exchange. The AS issues a ticket-granting ticket (TGT). The Ticket-Granting Service (TGS) is the KDC entry point that accepts a TGT. The TGS issues tickets for specific services. The application service is the target server that the client actually wants. Examples are a file, mail, or web service in the realm.
AS and TGS are different protocol entry points with different jobs. AS and TGS are often hosted together in one KDC. Co-located does not mean the same exchange.
The ticket path in three exchanges
First, the client asks the AS. In the usual case, the AS returns a TGT plus a session key for the TGS. Second, the client presents the TGT to the TGS. The client asks the TGS for a ticket to a specific service. The TGS returns a service ticket plus a session key for that service. Third, the client presents the service ticket and a fresh authenticator to the application service. The service decrypts the ticket with its own key. The service then checks the authenticator. RFC 4120 calls these steps the AS exchange, the TGS exchange, and the client/server (AP) exchange.
The habit is short. A TGT gets more tickets for the client. A service ticket authenticates the client to one specific service. A TGT is a ticket for the TGS itself, not for the file share. A service ticket for one service does not open a different service.
Realm policy sets ticket lifetimes. Lifetimes, clock skew values, and encryption types are owner decisions against current vendor and standards guidance.
What a ticket proves, and what still happens
A validated exchange gives the service cryptographic evidence about the client principal. That evidence holds within the trust of that realm. That evidence is authentication. RFC 4120 states that Kerberos does not, by itself, provide authorization. A ticket for a service only authenticates the client to that service. RFC 4120 advises applications not to treat the ticket as permission without a separate authorization step.
The service that receives the ticket still decides authorization. The service checks local policy, group membership, access control lists (ACLs), and its own application rules. Some deployments carry authorization data inside tickets. The service still interprets and enforces that data. A ticket in hand is not the same as permission to do everything.
SSO covers several ticket grammars
People use the term SSO for Kerberos on an enterprise network. People also use SSO for OAuth and OpenID Connect in browsers and apps. People also use SSO for SAML in enterprise web sign-in. Those are different protocol families with different objects, different audiences, and different validation rules. A debug starts with the right object.
A Kerberos service ticket is a KDC-issued authentication credential for a Kerberos service in a realm. An OAuth access token is an authorization credential for a resource API. An OIDC ID Token is an identity assertion to the client about an authentication event. A SAML assertion is an XML statement from an identity provider. Enterprise browser SSO often uses SAML assertions.
A protocol, not one product, and not obsolete
Kerberos is a protocol. Microsoft Active Directory is a very common deployment context. Many people first meet Kerberos in Active Directory. Kerberos is not only Active Directory. MIT Kerberos, Heimdal, and other implementations run Kerberos realms. Many computer platforms and services speak Kerberos.
Kerberos is also not obsolete. Version 5 remains in wide use for enterprise network authentication. Kerberos often sits beside federation protocols, and those protocols do not replace Kerberos.
Rewrite the SSO ticket sentence
The synthetic case starts with an employee who signs in to a workstation on a corporate network. The employee opens an internal file share without a second prompt. The employee then opens a SaaS dashboard through the company identity provider. A coworker states, "the SSO ticket let them in everywhere."
An exact rewrite follows. The workstation sign-in obtained a Kerberos TGT. The TGS issued a service ticket for the file share. The file share still checked its own permissions. The SaaS dashboard received a SAML assertion or an OIDC ID Token from the identity provider. The dashboard still decided what the account can do. The case has two protocol families, two objects, and two authorization decisions.
At work, the team privately asks the identity owner which protocol each app actually uses.
A Kerberos ticket is not every SSO ticket
| Phrase people use | Literacy correction |
|---|---|
| A Kerberos service ticket. | A Kerberos service ticket is a KDC-mediated authentication credential for a specific Kerberos service in a realm. The client presents the ticket with an authenticator. The ticket is not an OAuth access token, an OIDC ID Token, or a SAML assertion. |
| An OAuth access token. | An OAuth access token is an authorization credential that a client presents to a resource API. OAuth is a different protocol family from Kerberos. Lesson: /learn/topics/who-holds-the-ticket/ (IF1). Term: /reference/terms/oauth/. |
| An OIDC ID Token. | The ID Token reports an authentication event to the client. The ID Token is not an API credential and not a Kerberos ticket. Lesson: /learn/topics/assertion-claims-not-admin/ (IF2). Term: /reference/terms/oidc/. |
| A SAML assertion. | A SAML assertion is an XML assertion from an identity provider. The service provider still validates the assertion and still authorizes. Lesson: /learn/topics/federation-failure-modes/ (IF3). Term: /reference/terms/saml/. |
| I have a Kerberos ticket, so the app must allow every action. | A ticket authenticates the client to one service. The service still decides authorization from local policy, groups, ACLs, and app rules. Terms: /reference/terms/authentication/ and /reference/terms/authorization/. |
Common misconceptions
SSO means one ticket type, so Kerberos, OAuth, OIDC, and SAML are the same thing.
SSO is an experience, not one object. A Kerberos service ticket, an OAuth access token, an OIDC ID Token, and a SAML assertion come from different protocol families. Those families have different audiences and validation rules.
If Kerberos authenticates a user, the app must allow every action.
A ticket authenticates the client to a service. Authorization is a separate step that the service performs. The service still decides what the client can do.
Kerberos is only Active Directory, or Kerberos is obsolete.
Kerberos is a protocol with several implementations. Active Directory is a common deployment context, not the definition. Version 5 is still in wide use for enterprise network authentication.
Kerberos sends the password to each service that the user opens.
The client proves its identity to each service with a service ticket and a fresh authenticator. The password-derived key does not go on the wire to every service.
AS and TGS run in one KDC, so they are one exchange.
AS and TGS are different protocol entry points. The AS exchange issues the TGT. The TGS exchange issues service tickets. One KDC host does not merge the two exchanges.
CHECK THE CATEGORY
Which sentence matches Kerberos literacy?
Glossary and nearby pages
- Identity federation path: Trust tickets, not hallway trust
- IF1: Who holds the ticket, and what does it open? (OAuth access tokens)
- IF2: ID Token and SAML assertion are claims, not blank admin passes
- IF3: Five ways the ticket still burns you (federation failure modes)
- Authentication vs authorization (term guides)
- SP 800-63-4 explainer (assurance categories, not a ticket protocol)
- Privacy is not a CIA checkbox
Use the agency page in the sources for the authoritative text.