What is a difference between security token and security ticket?

Question

What is a difference between security token and security ticket?

I have seen these terms been used interchangeably. Are there "industry standard" definitions of these? or are these terms defined differently depending on technology/protocol/implementation?

Answer 1

The words token and ticket depend greatly on the type of system you're dealing with; and in what context you are talking. On Windows NT derivatives, the concept of a token is an identity. When a user or service logs in to a system, the system validates their identity once, and mints a token, which is handed to that user/service and serves as their identity. The system then doesn't need to validate identity every time a program opens a file, for example. This basically ensures a clean separation between authentication (proving a user/service is who they say they are) and authorization (determining whether a user/service can access some resource).

On the other hand, (again for NT derivatives) the word ticket usually refers to Kerberos tickets. These are used for two machines on a domain to be able to prove each others' identity. After proving one's identity to the domain controller (with traditional means such as password or smart card), the domain controller mints a ticket which can be passed to remote machines to verify identity.

If one is dealing with a remote machine, then it is likely both tickets and tokens are involved. For instance, if machine A opens a file share on machine B, then machine A validates the user using it with the domain controller, thus getting a Kerberos ticket. It then uses the Kerberos ticket to verify its identity with machine B. Machine B then creates a session for machine A, minting a token, to serve as that session identity for local authorization queries on machine B.

As Feral and Oded have elsewhere in this question though, this is very domain-specific language.

Answer 2

A security token becomes a security ticket after a request for service is successfully authenticated. For SOAP, after receiving a SOAP message as confirmation, that security ticket is used for all subsequent requests. I think of a security token as higher level, more strict, whereas a security ticket is issued by a service provider and more narrowly useful.

According to this (no longer current) MSDN article, Brokered Authentication: Security Token Service:

...the client obtains a Security Context Token (SCT) (which demonstrates that the client has been authenticated) from the STS and caches it. After the client is authenticated with the STS, the client can use the session token to request a service token for communication with a service. The way the STS validates a security token presented by a client and issues service tokens is similar to how the Kerberos protocol validates a ticket-granting ticket and issues a service ticket.

"Security token" has the same meaning as I am familiar with, but "service token" is used instead of "service ticket". The last part of the sentence, about Kerberos, reads really oddly i.e. a "ticket-granting ticket".

Here's another explanation, where the terminology is more familiar to me (it is specifically about SAML for Single Sign On):

SSO in its basic form just means that a service provider will trust authentication credentials provided using the SAML standard by an identity provider... Please note that when we use the term ‘token’, we’re not talking about some sort of physical security token, but something else entirely, a security ticket that is part of the SAML standard.

Now for the next part of your question, which was about standards. This blog post has four OASIS WS use cases for security tokens (policy?), with links to the standards. In case you have any problem accessing that, OASIS has a page of standards for security tokens.