Hmm, I don't see any mention of security. I can't find the source, but I remember reading that if you wanted to restrict access to certain pages on your site to authenticated users in a single page app it was more secure to do it server side. Security experts feel free to chime in.
It's not it was more secure,it's that it is impossible to secure anything on the client(native or html,by the way) if there is no interaction with a server doing access control somehow. That one reason why old facebook app was downloading HTML instead of having it bundled and just requesting json payloads).
What is a single page app? a single HTML file.How can you secure anything in a single HTML file? there are no "pages", the browser history is just tricked into pushing or poping url states.
You can however decide that an API call will fetch resources like js and css right after a user is logged in,but that's the server doing its job,and the assets would be served either through tokenized temporary URLs , or read on the server's disk , streamed through a server-side language then dumped in the client.
I bet that a majority of SPAs out there dont do that,and sensitive assets are downloadable even when a user isnt logged in.
A non authorized user shouldnt have accessed to these assets,or even endpoint URLs meant for authorized users.But yeah,it means using a proper server-side language and not just serving everything from S3.
Isn't the point of this not to secure some thing, as in "no access", but to sign something and trust it (i.e. a server signs a token and hands it off to another machine/app)?
If your point is "nothing is secure in the browser" then that includes the secured content sent down by a secure server no matter the method.
No idea if HelloJS is a secure client or not, but it's possible. Here's a good resource for how Google offers purely client-side OAuth to API consumers: https://developers.google.com/accounts/docs/OAuth2
I believe this is only possible since OAuth2. One important aspect is that the API provider registers the consumer's key along with their domain, so API requests using that key are only valid coming from that domain.
Probably you mean the FB API that doesn't restrict the redirect URL by default.
Google(+?) requires you to whitelist possible redirect URLs, meaning that it's much more obvious what happens after a redirect. Thus limiting what an attacker may do...
Using client-side script to restrict access is a big no from a security stand point. From what I have read this library is intended to interact with third party services rather than for access. E.g. pulling in photos, contacts etc
Assuming OAuth uses random numbers (don't remember if it does), one issue could be that the RNG of Javascript is not cryptographically secure. I'd be interested to hear the opinion of a security expert too.
I don't see any reason why it would need random numbers for OAuth 2.0. Part of the reasoning that went into the OAuth 2.0 spec is that not all applications might have access to encryption, so encryption should only be used at the protocol level (i.e. HTTPS).
As it requires an "OAuth proxy" for OAuth 1.0a and some implementations of OAuth 2.0, it seems that it offloads the crypto (and secret API key) to that proxy.
If the client passes the server a token which the server can verify against the third-party service providing the login, I don't see a reason not to trust the client. I'm very interested to hear what kind of security problems this could bring - if they can be mitigated, using this library would be very convenient for some projects.
I didn't look at this in detail, but this appears to also be using refresh tokens. Getting clarity on refresh tokens is a bit tough, but they are intended to allow one to request a new access token when the access token expires. I don't think refresh tokens are intended to be stored client-side as they are with this. If a refresh token is compromised, it can be used to request an access token for the user.
