representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. IETF JWT draft 32* * https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32
The issuer of the claim. Can be used to identify the service that issued the token. sub String The subject of the token. This is the consumer associated with the relevant action. aud String[] The audience of this token. Can be used to identify the recipients that the token is intended for. iat Long Issued-at time. Contains the UTC Unix timestamp at which the token was issued. exp Long Expiration time. Contains the UTC Unix timestamp after which token should no longer be accepted. Should be after the issued-at time. nbf Long Not before time. Contains the UTC Unix timestamp before which token sholud not be accepted. jti String The unique identifier of the token. * https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-4
superSafeSecret ) The signature can be computed using an algorithm specified in JWA (JSON Web Algorithms)*, such as: • HMAC SHA-256, • RSASSA-PKCS-v1_5 SHA-256, • etc. * https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-3
a strong key that is available only to the authentication service, • Rotate your keys frequently, • Keep expiration times reasonably short, • Server must verify that the token was signed with your secret key, • Use the tokens to fetch the data, not to store it, • Encrypt your tokens if you have to put sensitive, non-opaque information in them, • Use a custom claim that prevents URL tampering, e.g. URL hash, • Watch for XSS, • Never transmit tokens over a non-HTTPS connection.