More token taxonomizing

Generally, APIs fall into one of two categories –  either SOAP-based or REST-based. SOAP defines an XML messaging envelope for carrying payload and associated metadata. SOAP messages are typically delivered over HTTP as POSTs – the semantics of the message carried in the SOAP Body within the HTTP body. Advocates of REST argue that HTTP itself offers all the desired semantics through its built-in support for GET, PUT, POST, DEL etc. There is much emotion on both sides. Regardless, both SOAP and REST APIs rely on tokens to carry security information.

API Clients typically interact with some sort of 'token service' to get a token, and then include that token on their calls to the API - the token layers on the security information the API needs to make an authorization decision. For the SOAP world, WS-Trust defines the protocol between the Client and the token service by which the Client gets the necessary toklens. In the REST world, OAuth does the equivalent.

Tokens can be distinguished along a number of (somewhat) orthogonal axes:

• artifact or assertion - does the token have internal structure with heterogeneous elements within? Or is an opaque blob like a random text string that have no inherent meaning or semantics, but acts only as a reference or pointer into some store – the referenced object likely having the semantics. The artifact model has advantages when the delivery channel is constrained in security or size-limits
• Security model - what is required of the Client for presenting a token to some API? Is mere possession of the token sufficient (the bearer model), or is the Client required to demonstrate knowledge of some secret associated with the token (the POP or proof-of-possession model)?
• Implicit or explicit security. Does the token carry within itself its own inherent security protections, ie is there a space to carry a signature for the token, thereby allowing a recipient to determine the issuer of the token? Alternatively, does the token itself rely on external security protection, e.g. provided by the transport channel over which it is sent
• Standardized or proprietary – is the structure (if present) of the token defined by some group – or is it proprietary to a single issuer (or recipient). The criteria as to what constitutes ‘some group’ varies. If the same entity both issues and verifiers the tokens - there is less motivation for a standard (assuming they are opaque to the client)
• Duration - are they long-lived or short-lived? Generally, bearer tokens are given short lifetimes to balance the risk of their theft.