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

41–50 of 58 posts

Re: HelloJS – Client-side OAuth for JS

#41

Post by 1337badger »

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

Earlier quoted context omitted.

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

Usually the token kept in memory is one distributed by the application and is not that which the services send back. What is application in that sentence? The API? Isn't that what this lib does? A client-side Javascript SDK for authenticating with OAuth2 web services and querying their REST API's. - I assume the API issues the token - This lib receives it and uses it for subsequent calls - The token is destroyed when…

I am referring to the application you are writing

Re: HelloJS – Client-side OAuth for JS

#42

Post by logicalmind »

egeozcan wrote: post #17
pr0filer__ wrote: post #16

Earlier quoted context omitted.

From my understanding this is also the case ie. don't do OAuth client (end-user/browser) side.

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.

Re: HelloJS – Client-side OAuth for JS

#43

Post by joeframbach »

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?

Re: HelloJS – Client-side OAuth for JS

#45

Post by napoleond »

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.

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.

Re: HelloJS – Client-side OAuth for JS

#46

Post by hippich »

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?

may be if you change view on what and where software should be doing it might click together. i.e. for example all real work happens on client and client app offloads only storage of computed data to your servers via separate authentication. this is shift of paradigm back again to "desktopish apps", but still quite viable in certain situations.

Re: HelloJS – Client-side OAuth for JS

#47

Post by joeframbach »

hippich wrote: post #46
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?

may be if you change view on what and where software should be doing it might click together. i.e. for example all real work happens on client and client app offloads only storage of computed data to your servers via separate authentication. this is shift of paradigm back again to "desktopish apps", but still quite viable in certain situations.

And if you want to offer a desktop app, a web-based app, and native ios, android, fire, and tinzen apps, then all that client code is duplicated. And good luck if you need to update them all.

Re: HelloJS – Client-side OAuth for JS

#49

Post by pluma »

How does this get away with not using the client secret? I thought OAuth 2.0 always required a three-way handshake (client is sent to provider, provider sends client back to service, service exchanges grant token with the provider).

Does this mean in Facebook, Google etc the grant token and the access token are identical?

Re: HelloJS – Client-side OAuth for JS

#50

Post by pluma »

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.

It only has the `client_id` on the page. The `client_secret` is not disclosed to the user, although using it apparently requires using the "OAuth proxy".

I'm baffled this actually works. The entire idea is that the `client_id` can be disclosed to the user (via the login redirect) because the `client_secret` is required to verify the application's identity.

Post reply on HN