I don’t need to actually touch the token or even retrieve it as long as the token gets transferred into the header for the API call the same way it ends up in other requests the browser makes to the site. I believe I might be able to deal witht cross site scripting issues if need be, but I’d like to try avoid having to if possible. I just need a way to instruct the brower to treat my API get request the same as it would treat page level get requests. Is that possible?
MarthinL
derek-zhou
It is possible. Then you need to use the cookie based token, and do the following:
- your front end and api backend must be under the same apex domain
- your api backend must have a login UI and set the cookie on the apex domain
- your frond end must call the api backend with
Access-Control-Allow-Credentials - your api backend must white list the front end domain in
Access-Control-Allow-Origin - if your user has a valid token it should work now. if not, your api backend must return a
401 Unauthorizedand your front end should redirect to the login screen of your api backend. - if the user successfully log in to the api backend, it should redirect to the front end page found in the
refererheader
0
MarthinL
Thanks, it will take me a while to figure out how to get those things done, but I seems very possible.
As for the front- and back-end being on the same domain, that’s a given in my case since they are either the same machines or live in the same cluster of load-balanced containers at the same public address.
Will the api backend need a SEPERATE login UI from what is there already or can it use the same if I want. It might make sense at some point to redirect differently if the token expires while the user is still using the Vue app so none of their data is lost, but it would help if for a start a token authentication failure 401ing and redirecting to the one and only login page would be OK.
Would 'setting the cookie" be something I need to add manually or is it done in the generated login code already?
I shall go read up about the flags that would need to be set and where to inject those.
Thank you cery much.
Oh, one more thing. I hear about it but don’t understand the difference between cookie based token and whatever other option there is (bearer token perhaps?) and even less about what the risks and benefits are. Is there a simple way to explain that or wil I need to go read a bunch of articles to gain an understanding?
0
derek-zhou
If your api backend is at the apex then nothing is needed. If not, you need to add domain clause in your session option
Bearer token is in a different header and fully controlled by the frontend. So you can do cross domain api calls. You may not be able to use cookie in a mobile app, for example.
0
pupdogg
JWT tokens, just on the face value, are in-fact worse off then server-based sessions (specifically db stored sessions). Unlike server-based sessions, you cannot forcefully expire JWT tokens without having a sane JWT storage and a refresh-token strategy in place. So, until the JWT expires, these client side tokens are extremely vulnerable to any and all kinds of malicious attacks.
0
thojanssens1
Yep. I was then mentioning that it doesn’t make sense to say JWT, used as session mechanism, are “worse than sessions”. A session doesn’t always imply session data stored on the server. The post I replied to got deleted since then.
1