1. API Requests

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

2. Cookies

RFC 6265 - HTTP State Management Mechanism

RFC 6265 - Draft includuing the SameSite attribute

When the user is successfully signing or logging in, the registration API is sending back a Set-Cookie in the header of the response with two cookies seperated by a comma:

• access
• refresh

Set-Cookie Headers can be ignored by the browser only if the response of the API is informational / 100 level .

The access/refresh cookie contains the following information:

one set-cookie-header: "Set-Cookie:"

one set-cookie-string that contains at least a name-value-pair value but can also contain other attributes value:pair , in our case:

• cookie-pair: "access=[JWT]" or "refresh=[JWT]"

see next chapter

• domain-av: "Domain=[domain]"

domain of the host the cookies will be sent to

• expires-av: "Expires=[sane cookie date]

some browser do not support Max-Age, in this case the expires-av counts. It is the date when the cookie expires.

• httponly-av: "HttpOnly"

The HttpOnly attribute limits the scope of the cookie to HTTP requests. It means that the JS Code will never have access to it.

• max-age-av: "Max-Age=[non zero digit]

number of seconds until the cookie expires

• path-av: "Path=/"

cookie will only be sent if the path of the uri-request matches or is a subdirectory

• SameSite=Strict

cookie will only be sent when requests come from the same domain. this is not supported by all browser - so CSRF builtin protection from Django is still needed.

• Secure

will only be sent over secured connection (in our cases https and not http)

The front end sends then in every other request to all APIs (registration, user_management, game) the access cookie. When the access cookie is expired, a request with refresh cookie is sent to the registration API and the response is a new access token as well as a new refresh token

3. JSON Web Tokens (JWT)

RFC 7519 - JSON Web Token (JWT)

We are creating two JWTs (access and refresh tokens) after signing in, login and refreshing the access token. Our tokens contain the following information

Header

• "alg": "RS256"

see Signature

• "typ": "JWT"

(optional) recommended to be JWT - could have been JWS or JWE to be continued

Payload

• "exp": 1724663345

Expiration Time claim (optional): identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

• "iat": 1724661545

Issued at claim (optional)

• "jti": "db00494437eb45b097ef3ddd379d625d"

JWT ID claim (optional) - there should be no collision "user_id": "582b7bb4-ecfb-45e4-ba5e-5cf10460539c" the only information that we share since the user-id does not give any information.

Signature

Asymetric signatures. Only Registration has the private key to sign the JWTs. All the services can verify the signature with the public key but they cannot manipulate them.