Authentication: new phone, who dis?

Basic Access Authentication

Authentication: the process of verification that an individual, entity, or website is who it claims to be. Commonly performed by submitting a user name or ID with one or more items of private info that only a given user should possibly know.
Session Management: the process by which a server maintains the state of an entity interacting with it, which is necessary so the server knows who to react to subsequent requests made by our user throughout the transaction. Sessions are maintained on the server by a session ID that can be sent back and forth between the client and server. Sessions should always be unique per user and hard to predict.
A way for an HTTP client (such as your web browser) to give a user name and password when making a request. It's a simple way to enforce access controls on web resources as it does not need session ID's, cookies, or login pages.
BA's are not encrypted and provides no confidentiality protection, thus you should only use it when also using HTTPS.
The browser needs to cache the credentials provided for however log the user is on the website, or for a finite amount of time. We must make sure users credentials are able to be cleared in some way as HTTP does not give us a way to simply logout them out.

The JSON web token (JWT) defines a compact, self-contained way for securely transmitting data between different people/clients as a simple JSON object. The data transmitted is trustworthy and must be digitally signed for via secret key.
Signed tokens: are the way we confirm the integrity of the content.
Encrypted tokens simply hide the claims from other parties.

Authorization: Most common usage. User logs in to the site and all requests after that keep the authorized JWT.
Information Exchange: JWT securely transmit data between parties, and since they can be “signed”, we can confirm that the sender is indeed user actual. Signatures are calculated using the header and payload.

Three parts, separated by dots ( . ); header, payload, **signature **(or header.payload.signature).
Header: Two parts; type of token (JWT) and hashing algorithm used (HMAC, RSA, etc)
Payload: contains the claims about the user and additional data. Three types of claims; registered, public, private. Registered: set of recommended predefined claims (iss, exp, sub, etc) Public: defined at will by whomever is using JWT. Avoid collisions. Private: custom claims created to share information between parties that have agreed to them.
Do not put secret info in the payload or header elements of a JWT unless encrypted.
Signature: needs encoded header/payload, a secret, the algorithm specified in the header, and sign it. Used to verify the message was not changed enroute and verifies who sent it.
We can use “jwt.io Debugger” to decode, verify, and generate JWTs.

When authenticating, our user logs in using their credentials, a JWT is returned. Remember that Tokens = credentials. When users want to access something protected, user agent sends the JWT in the **Authorization **header using Bearer schema (eg: Authorization: Bearer )
Application (client) → Authorization Server → Application → Our API (resource server)

JWT is more compact than Security Assertion Markup Language Tokens (SAML).
JWT is more secure than Simple Web Tokens (SWT) since SWT can only be symmetrically signed by a shared secret using the HMAC algorithm.