8 ms·

HelloJS – Client-side OAuth for JS

160 points by sidi 12y ago

adodson 12y ago
Thanks for sharing my project HelloJS
- drcode 12y ago
  Hi... thanks for writing this. As a newb on these sorts of issues, I have some questions: 1. So this is 100% client side... Why do I see "npm" in the instructions? Isn't that connected to nodejs? What if I'm writing a java web server app, will this still work, or does it need to talk to a nodejs server somehow? 2. I take it none of this hits a third party server (i.e. your server)? 3. How do I get the user's info obtained via authentication (gmail address, etc) to my server, in a way that is secure, if this is all client & browser based?
  - adodson 12y ago
    Use node for bundling+minification. Its on npm for convenience. I also hope to make it compatible with CommonJs and have components of it work through the server. Not all services support server-less authentication otherwise known as Implicit OAuth2. As such, i've put a proxy service up on Heroku. Read up at http://adodson.com/hello.js/#oauth-proxy http://adodson.com/hello.js/#oauth-proxy
  - dubcanada 12y ago
    1. NPM is just an easy way to install it, you can also use bower or just download the source and minified packages. 2. I see no reason why it would. 3. It's all client based regardless of how you do it, it just adds cookies. If you want to get the information server side just get it server side (PHP example https://github.com/thephpleague/oauth2-client https://github.com/thephpleague/oauth2-client) there is no need to get it client side if you need it server side with a server side library (thus why NPM is shown as node is server side).
  - reubano 12y ago
    1. NPM is used for installing bower [1], a package manager for client side libraries. [1] http://bower.io/ http://bower.io/
- colordrops 12y ago
  Hi, thanks for putting this together and releasing it. I'd like to use it on our corporate intranet, but we use the OAuth2 implicit flow with JSON web tokens. Does hello.js support this use case?
  - adodson 12y ago
    I couldn't find any examples of JSON Web Token in the client. But if the security model supports it then i'd like to entertain the idea.
wyuenho 12y ago
HelloJS is great. I've used it in my last project. It just works. It's well tested, and well documented. There's very little option twiddling required. It just worked seemlessly when I was trying to setup Twitter, Google, LinkedIn and Facebook OAuth logins.
- adodson 12y ago
  Nice endorsement
j-rom 12y ago
This looks amazing. Are you planning on adding any other services?
- adodson 12y ago
  Yes, but its a pretty arduous task digesting and implementing API docs. That pain was the impetus to standardize them into the HelloJS library.
plingamp 12y ago
Very interesting project! Can you explain what some of the differences are between this library and PassportJS?
- reubano 12y ago
  Passport is sever and side meant for use with nodejs [1]. This is client side for use with bower [2]. [1] http://nodejs.org/ http://nodejs.org/ [2] http://bower.io/ http://bower.io/
- adodson 12y ago
  PassportJS = NodeJS authentication, designed for single sign-on. HelloJS = Browser + Phonegap authentication and API request handling designed to interact with thirdparty services from the client app.
  - technological 12y ago
    Firebase simple login does provide similar functionalities right ?
reubano 12y ago
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.
- pr0filer__ 12y ago
  From my understanding this is also the case ie. don't do OAuth client (end-user/browser) side.
  - egeozcan 12y ago
    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.
    - logicalmind 12y ago
      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.
- hackthisuk 12y ago
  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
- laurent123456 12y ago
  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.
ishi 12y ago
This looks pretty awesome. Could it be used for importing email contacts from gmail/yahoo/live etc.?
- adodson 12y ago
  @ishi take a look at this example http://adodson.com/hello.js/demos/friends.html http://adodson.com/hello.js/demos/friends.html
shaydoc 12y ago
This is great, perfect for little consumer web apps. I am so happy about this, becuase we (my dev buddies) have just had an idea for a little social game that would be great if ported onto the web. I think I have just solved our simplistic user auth needs by reading this article. Thanks for sharing.
sleepychu 12y ago
Oh my god the kerning on that font.
- joeframbach 12y ago
  I t o t a l l y a g r e e .
- adodson 12y ago
  Point and space taken. Now it is readable - and I rather dread the consequences.
1337badger 12y ago
This is a terrible idea that is full of security holes! If you can call having paper-thin pseudo security a hole.
- bikamonki 12y ago
  Security holes such as? Please elaborate.
  - 1337badger 12y ago
    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.
    - taylorbuley 12y ago
      Session store is a good place for these, purges on browser close. Or logout, and those api_tokens are no longer valid. To me, lightweight, throwaway tokens seems exactly the purpose of oAuth.
      - 1337badger 12y ago
        It really depends, it will purge on browser close yes but it still allows access that make not have been intended by your application for use by others also the refresh token may also be stored. The danger is in someone getting this token from an active session and using it outside of its intended parameters not the normal use case.
        heme 12y ago
        Not doubting you, but I would love to see the methods to make this happen. Is your concern from a 3rd party script included on the page? From my experience memory is safe between origins in the same way cookies are. And it is the dev's responsibility to not do something stupid with the token like window.FacebookToken = OAuthToken;. But that holds for traditional session cookies as well.
blueskin_ 12y ago
Client-side authentication. In javascript. What could possibly go wrong? ;)
knackers 12y ago
Looks great. It's such a pain to write separate authentication / profile retrieval logic for each service.
joeframbach 12y ago
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?
- hippich 12y ago
  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.
  - joeframbach 12y ago
    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.
- deleted 12y ago
  [deleted]
- tracker1 12y ago
  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.
bzelip 12y ago
I really like adodson's web game. Check out http://adodson.com/#escape http://adodson.com/#escape for browser MineField & Flood It.
pluma 12y ago
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?
tsmash 12y ago
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?
- adodson 12y ago
  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 https://github.com/MrSwitch/hello.js/issues/22

160 points by sidi 12y ago

adodson 12y ago

Thanks for sharing my project HelloJS

drcode 12y ago
Hi... thanks for writing this. As a newb on these sorts of issues, I have some questions: 1. So this is 100% client side... Why do I see "npm" in the instructions? Isn't that connected to nodejs? What if I'm writing a java web server app, will this still work, or does it need to talk to a nodejs server somehow? 2. I take it none of this hits a third party server (i.e. your server)? 3. How do I get the user's info obtained via authentication (gmail address, etc) to my server, in a way that is secure, if this is all client & browser based?
- adodson 12y ago
  Use node for bundling+minification. Its on npm for convenience. I also hope to make it compatible with CommonJs and have components of it work through the server. Not all services support server-less authentication otherwise known as Implicit OAuth2. As such, i've put a proxy service up on Heroku. Read up at http://adodson.com/hello.js/#oauth-proxy http://adodson.com/hello.js/#oauth-proxy
- dubcanada 12y ago
  1. NPM is just an easy way to install it, you can also use bower or just download the source and minified packages. 2. I see no reason why it would. 3. It's all client based regardless of how you do it, it just adds cookies. If you want to get the information server side just get it server side (PHP example https://github.com/thephpleague/oauth2-client https://github.com/thephpleague/oauth2-client) there is no need to get it client side if you need it server side with a server side library (thus why NPM is shown as node is server side).
- reubano 12y ago
  1. NPM is used for installing bower [1], a package manager for client side libraries. [1] http://bower.io/ http://bower.io/
colordrops 12y ago
Hi, thanks for putting this together and releasing it. I'd like to use it on our corporate intranet, but we use the OAuth2 implicit flow with JSON web tokens. Does hello.js support this use case?
- adodson 12y ago
  I couldn't find any examples of JSON Web Token in the client. But if the security model supports it then i'd like to entertain the idea.

wyuenho 12y ago

HelloJS is great. I've used it in my last project. It just works. It's well tested, and well documented. There's very little option twiddling required. It just worked seemlessly when I was trying to setup Twitter, Google, LinkedIn and Facebook OAuth logins.

adodson 12y ago
Nice endorsement

j-rom 12y ago

This looks amazing. Are you planning on adding any other services?

adodson 12y ago
Yes, but its a pretty arduous task digesting and implementing API docs. That pain was the impetus to standardize them into the HelloJS library.

plingamp 12y ago

Very interesting project! Can you explain what some of the differences are between this library and PassportJS?

reubano 12y ago
Passport is sever and side meant for use with nodejs [1]. This is client side for use with bower [2]. [1] http://nodejs.org/ http://nodejs.org/ [2] http://bower.io/ http://bower.io/
adodson 12y ago
PassportJS = NodeJS authentication, designed for single sign-on. HelloJS = Browser + Phonegap authentication and API request handling designed to interact with thirdparty services from the client app.
- technological 12y ago
  Firebase simple login does provide similar functionalities right ?

reubano 12y ago

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.

pr0filer__ 12y ago
From my understanding this is also the case ie. don't do OAuth client (end-user/browser) side.
- egeozcan 12y ago
  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.
  - logicalmind 12y ago
    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.
hackthisuk 12y ago
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
laurent123456 12y ago
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.

ishi 12y ago

This looks pretty awesome. Could it be used for importing email contacts from gmail/yahoo/live etc.?

adodson 12y ago
@ishi take a look at this example http://adodson.com/hello.js/demos/friends.html http://adodson.com/hello.js/demos/friends.html

shaydoc 12y ago

This is great, perfect for little consumer web apps. I am so happy about this, becuase we (my dev buddies) have just had an idea for a little social game that would be great if ported onto the web. I think I have just solved our simplistic user auth needs by reading this article. Thanks for sharing.

sleepychu 12y ago

Oh my god the kerning on that font.

joeframbach 12y ago
I t o t a l l y a g r e e .
adodson 12y ago
Point and space taken. Now it is readable - and I rather dread the consequences.

1337badger 12y ago

This is a terrible idea that is full of security holes! If you can call having paper-thin pseudo security a hole.

bikamonki 12y ago
Security holes such as? Please elaborate.
- 1337badger 12y ago
  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.
  - taylorbuley 12y ago
    Session store is a good place for these, purges on browser close. Or logout, and those api_tokens are no longer valid. To me, lightweight, throwaway tokens seems exactly the purpose of oAuth.
    - 1337badger 12y ago
      It really depends, it will purge on browser close yes but it still allows access that make not have been intended by your application for use by others also the refresh token may also be stored. The danger is in someone getting this token from an active session and using it outside of its intended parameters not the normal use case.
      - heme 12y ago
        Not doubting you, but I would love to see the methods to make this happen. Is your concern from a 3rd party script included on the page? From my experience memory is safe between origins in the same way cookies are. And it is the dev's responsibility to not do something stupid with the token like window.FacebookToken = OAuthToken;. But that holds for traditional session cookies as well.

blueskin_ 12y ago

Client-side authentication. In javascript. What could possibly go wrong? ;)

knackers 12y ago

Looks great. It's such a pain to write separate authentication / profile retrieval logic for each service.

joeframbach 12y ago

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?

hippich 12y ago
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.
- joeframbach 12y ago
  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.
deleted 12y ago
[deleted]
tracker1 12y ago
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.

bzelip 12y ago

I really like adodson's web game. Check out http://adodson.com/#escape http://adodson.com/#escape for browser MineField & Flood It.

pluma 12y ago

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?

tsmash 12y ago

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?

adodson 12y ago
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 https://github.com/MrSwitch/hello.js/issues/22