!!! Overview
Modern [authentication] and/or [authorization] solutions have introduced the concept of tokens into their [protocols]. 

Tokens are specially crafted pieces of data that carry just enough information to either authorize the user to perform an action, or allow a client to get additional information about the authorization process (to then complete it). In other words, tokens are pieces of information that allow the authorization process to be performed. Whether this information is readable or parsable by the client (or any party other than the authorization server) is defined by the implementation. The important thing is: the client gets this information, and then uses it to get access to a resource.[2]

Tokens are [Claims]

A [{$pagename}] maybe physical ([Hard tokens] or a [message] ([Soft tokens]).

!! Why use [{$pagename}]s
[Why Use Tokens]

!! Passing [{$pagename}][1]
As you start implementing [{$pagename}]s, you’ll find that you have more tokens than you ever knew what to do with! How you pass these around your system will certainly affect your overall security. There are two distinct ways in which they are passed:
* [By-value] - Where the value of the [{$pagename}] is within the [{$pagename}] and if sensitive may require [Encryption]
* [By-reference] - Which is typically referred to as [Tokenization]
These are analogous to the way programming language pass data identified by variables. The run-time will either copy the data onto the stack as it invokes the function being called (by value) or it will push a pointer to the data (by reference). In a similar way, tokens will either contain all the identity data in them as they are passed around or they will be a reference to that data.

! TIP
Pass by reference when [{$pagename}]s have to leave your network, and then convert them to by-value tokens as they enters your space. Do this conversion in your API gateway.

If you pass your tokens by reference, keep in mind that you will need a way to dereference the token. This is typically done by the API calling an [endpoint] exposed by your API server or using a [Token Service Provider] or a [Security Token Service].

!! [GlobalPlatform] [{$pagename}]
[GlobalPlatform] defines [{$pagename}] as: "Data derived from a credential." (Which make so little sense, the discussions around [Tokenization] revolves around passing [By-reference]).!! [{$pagename}] Types
A [{$pagename}] maybe a:
* [bearer Token]
* [Sender Constrained Token]
* [access Token]
* [Identity Token]
* [Payment Token]
* [Password Token]
* [Hard tokens]
* [Soft tokens]
* [One-time password device tokens] 
* [JSON Web Tokens]
* [WS-Security Tokens]
* [Password tokens|Password]
* [Legacy Tokens] (e.g., those issued by a Web Access Management system)
* Custom Tokens are the most prevalent when passing them around by reference

The usages of each type of [{$pagename}] or a [combination of Tokens|Multi-Factor Authentication] determines the [NIST] [Level Of Assurance] is described in the [NIST Electronic Authentication Guideline] and increases the [Level Of Assurance] as applied to [Identity Assurance] as to the Identity being asserted.

[Authentication] systems that incorporate all three factors are stronger than systems that only incorporate one or two of the factors. The system may be implemented so that multiple factors are presented to the verifier, or some factors may be used to protect a secret that will be presented to the verifier. 

For example, consider a hardware device that holds a cryptographic key. The key might be activated by a password or the hardware device might include a biometric capture device and uses a biometric to activate the key. Such a device is considered to effectively provide two factor authentication, although the actual authentication protocol between the verifier and the [claimant|Digital Identity] simply proves [possession|Possession Factor] of the key.

The secrets are often based on either public key pairs [Asymmetric Key Cryptography] or shared secrets. A public key and a related private key comprise a public key pair. The private key is used by the [claimant|Digital Identity] as a token. A verifier, knowing the [claimant|Digital Identity]’s public key through some credential (typically a public key certificate), can use an authentication protocol to verify the [claimant|Digital Identity]’s identity, by proving that the [claimant|Digital Identity] has control of the associated private key token (proof of possession).

Shared secrets use either [Symmetric Key Cryptography] or passwords. In a protocol sense, all shared secrets are similar, and can be used in similar authentication protocols; however, passwords, since they are often committed to memory, are something the [claimant|Digital Identity] knows, rather than something he has. Passwords, because they are committed to memory, usually do not have as many possible values as cryptographic keys, and, in many protocols, are vulnerable to network attacks that are impractical for keys. 

Moreover the entry of passwords into systems (usually through a keyboard) presents the opportunity for very simple keyboard logging or “shoulder surfing” attacks. Therefore keys and passwords demonstrate somewhat separate authentication properties (something you know rather than something you have). Passwords often have lesser resistance to network attacks. However, when using either public key pairs or shared secrets, the subscriber has a duty to maintain exclusive control of his token, since possession and control of the token is used to authenticate the subscriber’s identity.

[Biometrics|Inherence Factor] are unique personal attributes that can be used for [Identification] of a [Natural Person]. They include [Facial recognition], [Fingerprint recognition], [DNA], [Iris recognition] and [Retinal recognition], voiceprints and many other things. [Biometrics|Inherence Factor] are used in the [Biometric Enrollment] to be able to later prevent a subscriber who in fact registered from repudiating the registration, to help identify those who commit registration fraud, and to unlock [tokens].

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Passing Tokens|dicapis.com/api-security-oauth-openid-connect-depth/|target='_blank'] - based on data observed:2015-05-18
* [#2] - [Refresh Tokens: When to Use Them|https://auth0.com/blog/2015/10/07/refresh-tokens-what-are-they-and-when-to-use-them//|target='_blank'] - based on information obtained 2016-05-15-