Currently, the server passes the tokens to the frontend through the URL, which is then parsed out and stored by the client. When the client tries to use expired tokens, I have some unpushed functionality in which the express app is able to negotiate with the spotify server to refresh the token and complete the request, which is then returned along with the request's JSON for the client to parse out and reuse for subsequent requests.
However, the client shouldn't even have the tokens. It's a security risk. Instead, the server should store the token associated with the user. When a user authenticates, the token is generated and stored by the server and mapped to that user. When the user makes a request, the server fills in their respective token. If the token is expired, the server gets a new token. This would be functionality that is required before deployment to ensure that the server is able to operate as intended on its own
Currently, the server passes the tokens to the frontend through the URL, which is then parsed out and stored by the client. When the client tries to use expired tokens, I have some unpushed functionality in which the express app is able to negotiate with the spotify server to refresh the token and complete the request, which is then returned along with the request's JSON for the client to parse out and reuse for subsequent requests.
However, the client shouldn't even have the tokens. It's a security risk. Instead, the server should store the token associated with the user. When a user authenticates, the token is generated and stored by the server and mapped to that user. When the user makes a request, the server fills in their respective token. If the token is expired, the server gets a new token. This would be functionality that is required before deployment to ensure that the server is able to operate as intended on its own