Clojurians Log v2

Any opinions on how HTTP requests and authentication should be managed on a SPA that has to communicate with multiple servers on different domains? Obviously saving auth data only in the backend's session is most secure, but this would mean all requests from the SPA need to be proxied through this backend. On the other hand, using localstorage to store auth data is less secure, and the SPA would still need to send OPTIONS preflight requests, which also is a performance penalty. Which is actually better from a performance standpoint?

I'm no expert by any regard but normally for this kind of situation I use a middleman backend which talks to all the secondary servers

So auth can be shared but also remains in the backend

I don't really know the performance implications in your original question, unfortunately

Yea, I think that's the most common. I just wonder how much it affects performance, as all requests will essentially have a detour added to them. This SPA is a frontend to multiple biological databases managed by different organizations, and it's up to the user to decide which server to use.

> using localstorage to store auth data is less secure What do you mean by auth data? I don’t see a problem with having session cookies set by different servers.

(Maybe overkill) You can look at the PKCE Oauth Flow, that is meant to securely obtain an access token for your APIs (say a JWT) without having to trust the client in storing some form of secret

and yeah, don’t store anything sensitive in localStorage, it’s not secure

To elaborate, storing tokens in localstorage can mean tokens can get stolen by XSS attacks

By auth data I mean tokens, and yes I'm aware of XSS.

@regen We use an OAuth flow for this: an Auth Server (that just hands out tokens), a Login Server for actual authentication, and then all the other services invoked from our SPA pass the access token.

(and the SPA talks to the Auth Server periodically to update its access token from the refresh token that it got from the Auth Server after login)

https://ocaml.org/ is erroring out 😞

it works for me right now?

it's a great language, one of my favorites

@regen I would go with the broker backend. This will limit your auth complexity to the broker and provide more flexibility for security. It also means that if any of the services you need to access change their auth processes or add new auth services, you only need to update the broker, not every client. The downside is that it will increase network traffic, may represent a single point of failure, could be a performance bottleneck and provides a rich target for adversaries. This type of question is challenging because the right answer also depends a lot on context. The level of threat and associated risk depends a lot on the types of services your accessing and the value (to others) of the data you need to protect. My preference has been for a architecture similar to what @seancorfield outlines. The additional traffic querying the auth server is minimal and having tokens with timeouts and authz as well as authn info provides a lot of flexibility and you can control access from a single point.

back up now i guess

yeah i've been dabbling recently. i really miss HM type systems

I've been having some fun with zig lately - it simplifies a lot of the cruftiness of C while being as low level, and adds HM type inference as well

c : c++ :: zig : rust, more or less

also zig does modules the same way OCaml does, they are data structures