Here is how you can use a cookie for your question regarding the access_token
:
1. Storing the cookie on the client:
document.cookie='access_token=[value]'
where [value]
is the token value.
If we use a reader/writer library that MDN provides here, we can do the above as:
docCookies.setItem('access_token', [value]);
The reason why we would use something like this instead of the standard way is to make it easier to access and delete the token, as demonstrated in #3 below.
2. Passing the cookie back to the server:
We need to send the access_token
back to the server through the header.
This should automatically be done for you, assuming that the server sends a response after authentication like Set-Cookie: access_token=[value]
.
If for any reason you encounter an issue regarding Access-Control-Allow-Origin
, here is an example of how you can set Access-Control
response headers for CORS:
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization
3. Deleting the cookie:
Using the reader/writer library linked in #1, we can do the following:
docCookies.removeItem('acccess_token');
Security considerations when using cookies for authorization:
XSS, MITM, and CSRF attack vectors should be considered when using cookies for authorization. On a basic level:
- For XSS attacks, we can set the
HttpOnly
flag in the response header by the server to prevent a client side script from accessing the cookie.
- For MITM attacks, we can use the
Secure
flag to guarantee the cookie is not sent over an unencrypted HTTP channel.
- For CSRF attacks, the recommendation by OWASP is the Synchronizer Token Pattern. It's basically a randomly generated token that is sent by the server and is sent back by the client to verify a request submission done by the user.