JSON Web Token is an open standard for secure transmitting information as a JSON object. JWT can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

• Authorization. Once the user is logged in, each subsequent request will include the JWT.
• Information Exchange. Because JWTs can be signed you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

• Header

  {
    "alg": "HS256",
    "typ": "JWT"
  }

• Payload

  {
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true
  }

• Signature

  HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret
  )

1. The application or client requests authorization to the authorization server. This is performed through one of the different authorization flows. For example, a typical OpenID Connect compliant web application will go through the /oauth/authorize endpoint using the authorization code flow.
2. When the authorization is granted, the authorization server returns an access token to the application.
3. The application uses the access token to access a protected resource (like an API).

An HTTP cookie is a piece of data a server sends with specific headers to a browser. The browser then uses it when communicating back to the server.

• Session management. Logins, shopping carts, game scores, or anything else the server should remember
• Personalization. User preferences, themes, and other settings
• Tracking. Recording and analyzing user behavior

Cookies today aren't indeed to be used as storage. For this purpose, there are Web Storage API (localStorage and sessionStorage) and IndexedDB.

Cookies are pretty simple in usage.

1. Server sets cookie with one or more Set-Cookie headers.
2. Browser stores cookie and provide future requests to the same server with Cookie header containing this cookie, until it expires.

• Expires=<date>
• Max-Age=<number-of-seconds> (has precedence over Expires)
• Domain=<domain-value>
• Path=<path-value>
• Secure - only for https: requests (except on localhost)
• HttpOnly - with no access for the client's JavaScript to this cookie
• SameSite - controls whether a cookie is sent with cross-origin requests
  • Strict - a cookie is sent only for the same-site requests
  • Lax - default, is sent when a user is navigating to the origin site from an external site and isn't sent for other cross-origin requests
  • None - a cookie is sent for both same-site and cross-origin requests, only works with the Secure attribute

• Secure - Man-in-the-Middle
• HttpOnly - XSS
• SameSite - CSRF

While browsing the web, you've almost certainly come across sites that let you log in using your social media account. The chances are that this feature is built using the popular OAuth 2.0 framework.

The basic OAuth process is widely used to integrate third-party functionality that requires access to certain data from a user's account. For example, an application might use OAuth to request access to your email contacts list so that it can suggest people to connect with. However, the same mechanism is also used to provide third-party authentication services, allowing users to log in with an account that they have with a different website.

OAuth 2.0 was originally developed as a way of sharing access to specific data between applications. It works by defining a series of interactions between three distinct parties, namely a client application, a resource owner, and the OAuth service provider.

• Client application - The website or web application that wants to access the user's data.
• Resource owner - The user whose data the client application wants to access.
• OAuth service provider - The website or application that controls the user's data and access to it. They support OAuth by providing an API for interacting with both an authorization server and a resource server.

Although not originally intended for this purpose, OAuth has evolved into a means of authenticating users as well.

1. The user chooses the option to log in with their social media account. The client application then uses the social media site's OAuth service to request access to some data that it can use to identify the user. This could be the email address that is registered with their account, for example.
2. After receiving an access token, the client application requests this data from the resource server, typically from a dedicated /userinfo endpoint.
3. Once it has received the data, the client application uses it in place of a username to log the user in. The access token that it received from the authorization server is often used instead of a traditional password.

OAuth authentication vulnerabilities arise partly because the OAuth specification is relatively vague and flexible by design. It includes many configuration settings that are necessary for keeping users' data secure.

• Improper implementation of the implicit grant type LABS
• Flawed CSRF protection LABS

• Leaking authorization codes and access tokens LABS
• Flawed scope validation
• Unverified user registration

• Require client applications to register a whitelist of valid redirect_uris. Wherever possible, use strict byte-for-byte comparison to validate the URI in any incoming requests. Only allow complete and exact matches rather than using pattern matching. This prevents attackers from accessing other pages on the whitelisted domains.
• Enforce the use of the state parameter. Its value should also be bound to the user's session by including some unguessable, session-specific data, such as a hash containing the session cookie. This helps protect users against CSRF-like attacks. It also makes it much more difficult for an attacker to use any stolen authorization codes.
• On the resource server, make sure you verify that the access token was issued to the same client_id that is making the request. You should also check the scope being requested to make sure that this matches the scope for which the token was originally granted.

• Make sure you fully understand the details of how OAuth works before implementing it. Many vulnerabilities are caused by a simple lack of understanding of what exactly is happening at each stage and how this can potentially be exploited.
• Use the state parameter even though it is not mandatory.
• Send a redirect_uri parameter not only to the /authorization endpoint but also to the /token endpoint.
• When developing mobile or native desktop OAuth client applications, it is often not possible to keep the client_secret private. In these situations, the PKCE (RFC7638) mechanism may be used to provide additional protection against access code interception or leakage.
• If you use the OpenID Connect id_token, make sure it is properly validated according to the JSON Web Signature, JSON Web Encryption, and OpenID specifications.
• Be careful with authorization codes - they may be leaked via Referer headers when external images, scripts, or CSS content is loaded. It is also important to not include them in the dynamically generated JavaScript files as they may be executed from external domains via <script> tags.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent (e.g. a web browser) to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic , where credentials is the Base64 encoding of ID and password joined by a single colon :.

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS/TLS should be used with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

Because the BA field has to be sent in the header of each HTTP request, the web browser needs to cache credentials for a reasonable period of time to avoid constantly prompting the user for their username and password. Caching policy differs between browsers.

HTTP does not provide a method for a web server to instruct the client to "log out" the user.

• Using HTTP cookies (MDN)
• OAuth 2.0 authentication vulnerabilities