Hello, thanks for sharing. In my experience, even with the sample project I shared, the browser always attaches it when you correctly configure the HTTP client and the backend server.
Can you please share a scenario where this won't be the case ?
If you try to run your example in a setup where the domains are actually different (for cookie purposes, browsers don't count different ports as different domains see this RFC: stackoverflow.com/questions/161217...), it will fail. You have to enable 3rd party cookies to make it work, which comes disabled by default (in Safari at least and probably in all modern browsers)
Thanks for sharing this. The only scenario where it works seamlessly is in a situation where both sites run on the same domain (can be different subdomains, but must be the same domains).
This actually makes me very curious. How do third-party authentication providers persist sessions ? Take Auth0 for example, how do they persist sessions for the application they're authenticating, given its on a different domain?
Looking at the source code now for auth0-spa-js, and if you have a chance, please have a look. You might see what I can't see.
You're right, if you set the cookie with the right domain pattern (i.e. .example.com) it should work between subdomains, but would still fail between domains.
One of the way you can use Auth0 is similar to what you've presented here, more or less, at least when it comes to third party cookies. Then again they don't recommend it (auth0.com/docs/login/embedded-logi...) and it doesn't work on many modern browsers (you can mitigate this by using a custom domain)
Also, it makes little sense to keep the bearer token in memory: whomever has access to the localStorage through XSS can scan the window object as well.
Hello, thanks for sharing. In my experience, even with the sample project I shared, the browser always attaches it when you correctly configure the HTTP client and the backend server.
Can you please share a scenario where this won't be the case ?
If you try to run your example in a setup where the domains are actually different (for cookie purposes, browsers don't count different ports as different domains see this RFC: stackoverflow.com/questions/161217...), it will fail. You have to enable 3rd party cookies to make it work, which comes disabled by default (in Safari at least and probably in all modern browsers)
Thanks for sharing this. The only scenario where it works seamlessly is in a situation where both sites run on the same domain (can be different subdomains, but must be the same domains).
This actually makes me very curious. How do third-party authentication providers persist sessions ? Take Auth0 for example, how do they persist sessions for the application they're authenticating, given its on a different domain?
Looking at the source code now for auth0-spa-js, and if you have a chance, please have a look. You might see what I can't see.
You're right, if you set the cookie with the right domain pattern (i.e.
.example.com) it should work between subdomains, but would still fail between domains.One of the way you can use Auth0 is similar to what you've presented here, more or less, at least when it comes to third party cookies. Then again they don't recommend it (auth0.com/docs/login/embedded-logi...) and it doesn't work on many modern browsers (you can mitigate this by using a custom domain)
Also, it makes little sense to keep the bearer token in memory: whomever has access to the
localStoragethrough XSS can scan thewindowobject as well.The
localStorageandwindoware globals. Is presumably easier to extract info from globals then from the encapsulated application logic code.