You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a scenario where a consumer application is using API to manage user authentication (like Publish), it's likely that bearer tokens will be stored somewhere on a client to act as session tokens. When this happens, it's important to verify with API that the token stored is still valid, allowing the application to redirect users to a sign in form if not.
Currently, Publish is hitting the /api/client endpoint in order to validate a token, obtaining useful information about the user in the process (killing two birds with one stone kind of thing). However, I wonder if it would be useful to create an endpoint that does nothing but validate an existing token, with the benefit of not having to hit the database at all. This endpoint would simply be validating the JWT and returning an empty response with an appropriate status code.
In a scenario where a consumer application is using API to manage user authentication (like Publish), it's likely that bearer tokens will be stored somewhere on a client to act as session tokens. When this happens, it's important to verify with API that the token stored is still valid, allowing the application to redirect users to a sign in form if not.
Currently, Publish is hitting the
/api/client
endpoint in order to validate a token, obtaining useful information about the user in the process (killing two birds with one stone kind of thing). However, I wonder if it would be useful to create an endpoint that does nothing but validate an existing token, with the benefit of not having to hit the database at all. This endpoint would simply be validating the JWT and returning an empty response with an appropriate status code.Useful? Micro-optimisation? 🤷♂️
cc @jimlambie
The text was updated successfully, but these errors were encountered: