Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HelloJS – Client-side OAuth for JS

adodson.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: HelloJS – Client-side OAuth for JS

#51

Post by pluma »

laurent123456 wrote: post #20
reubano wrote: post #13

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.

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.

Re: HelloJS – Client-side OAuth for JS

#52

Post by [deleted] »

joeframbach wrote: post #43

Could you explain why I should favor client-side auth over server-side auth, especially if I want to do some action on behalf of the user, like generating word-clouds of their posts, etc. And what makes helloJS different from oauth.io, which has open-sourced their server?

[deleted]

Re: HelloJS – Client-side OAuth for JS

#53

Post by tsmash »

Once you're authenticated in a client web page, lets say you want to perform data storage on your own server using this authenticated user as validation. How would your server validate the user's login is valid to accept user actions?

Re: HelloJS – Client-side OAuth for JS

#54

Post by tracker1 »

joeframbach wrote: post #43

Could you explain why I should favor client-side auth over server-side auth, especially if I want to do some action on behalf of the user, like generating word-clouds of their posts, etc. And what makes helloJS different from oauth.io, which has open-sourced their server?

One example I can think of would be a mail reader application, that ties the storage of their application to say DropBox. You can have the user authenticate their dropbox, so their account details won't even need to be stored on the server. This would work well for a chrome/firefox application for that matter.

I can think of a few other systems where it would be useful, but in general an application interface (including offline support) comes to mind here.

Re: HelloJS – Client-side OAuth for JS

#55

Post by tracker1 »

1337badger wrote: post #36
heme wrote: post #35

Earlier quoted context omitted.

Is not a session cookie the same thing? I'd argue if your tokens only live in memory they can be more secure. It also depends how long your tokens live or how many requests they are good for. No?

Usually the token kept in memory is one distributed by the application and is not that which the services send back. This allows greater restriction on actions and make it far easier to revoke effectively

The token in this case is for the local user, that you know, logged into the service in question... How is it insecure for my browser, with me in front of it, to be logged into facebook? I mean, yes, if you're using anything other than a session cookie or sessionStorage, there's risk from other users on the system... but with an SPA, without any hard storage, it's no less secure than using that site/app.

Re: HelloJS – Client-side OAuth for JS

#57

Post by adodson »

tsmash wrote: post #53

Once you're authenticated in a client web page, lets say you want to perform data storage on your own server using this authenticated user as validation. How would your server validate the user's login is valid to accept user actions?

Make a server-to-server call using the token to check its validity.

There's more comments on this subject here https://github.com/MrSwitch/hello.js/issues/22

Re: HelloJS – Client-side OAuth for JS

#58

Post by bikamonki »

1337badger wrote: post #32
bikamonki wrote: post #31

Earlier quoted context omitted.

Security holes such as? Please elaborate.

From what I gather you are leaving the api_tokens for the services in local memory. This means that the user or anyone else that can get there hands on the token can act on the service providers api masquerading as your application.

Well, assuming that the front-end app is served through SSL (avoid MITM), the only other possible hole I see is physical access to the machine while the browser tab is open, no? Can other browser tabs, malware or browser plugins access memory while the app is running?
Post reply on HN