JWT Authentication

In Frontegg, JWTs are extensively used in the form of an access Tokens.

What Problems do JWT Solve?

While the main purpose of a JWTs is to transfer claims between two parties, arguably the most
important aspect of this is the standardization effort in the form of a simple, optionally validated
and/or encrypted, container format. What JWT brings to the table is a simple, useful, standard container
format.

JWT Token Signature

A common method for attacking a signed JWT is to remove tis signature. Signed JWTs
are constructed from three different parts: the header, the payload, and the signature. These three
parts are encoded separately. As such, removing the signature and then changing the
header to claim the JWT is unsigned is possible. This is easily solved by ensuring the application that performs the
validation does not consider unsigned JWTs valid.

Setting JWT Cookie Policy

πŸ‘

Lax and Strict Attributes

Note that Lax and Strict attributes are particularly important for mitigating certain security vulnerabilities, such as Cross-Site Request Forgery (CSRF) and Cross-Site Script Inclusion (XSSI) attacks, which can be exploited if cookies are sent with certain types of cross-origin requests. By setting SameSite to Lax or Strict, you can control how cookies are shared across different origins and enhance the security of your app.

Frontegg Authentication uses cookies. To prevent the browser from sending this cookie along with cross-site requests you will need to set the SameSite cookie attribute to one of the following Levels: None, Lax, or Strict. Lax and Strict are the two values which are used in the SameSite attribute of HTTP cookies to specify how cookies should be sent by the browser when making cross-origin requests:

  1. Lax:

    • When a cookie is set with SameSite=Lax, the cookie will be sent with cross-origin GET requests. This means that if your website (the origin where the cookie is set) links to another website (cross-origin), the cookie will be sent with the GET request to that other website.
    • However, the cookie won't be sent in other situations, such as when making a POST request or when following a link with an HTTP method other than GET (e.g., a DELETE request).
  2. Strict:

    • When a cookie is set with SameSite=Strict, the cookie is not sent with any cross-origin requests. It will only be sent in requests originating from the same site (i.e., requests to the same origin where the cookie was set).
    • This provides a higher level of security and privacy, as it ensures that the cookie is not exposed to other websites.

JWT Token Expiration