This is a very nice solution and API for the front-end. It took me a couple part-time months to put together a similar (not modularized) solution for a rewrite of Plunker. There is quite a bit of juggling of information to do to pass around the appropriate information between client, server and auth providers that seems to have been nicely abstracted.
There were three major challenges for me in my implementation and I'm wondering how these could be addressed with Satellizer:
1. Anonymous content creation that can be attributed to a user upon sign-up or sign-in. On Plunker, anonymous users can create 'plunks' that will then attributed to them if they decide to register. This is important to allow streamlined user acquisition.
2. Account merging when someone accidentally creates two different user accounts with different social identities. This gets weird when anonymous content creation is involved since someone could create content while signed out and would need all that content re-attributed when they sign in.
3. Multi-provider authentication. In Plunker, certain features will only be available if the user has linked (for example) Dropbox. This means consumers of the api need to be able to add / remove social identities to / from users.
Hope to hear how you might attack these problems with something like Satellizer (or other people's approaches that have worked).
The account merging part is something your server should handle.
In my app I maintain a users table that has columns (google_account_id, facebook_account_id, twitter_account_id, etc), pointing to individual rows in a separate accounts tables (e.g. google_accounts, facebook_accounts, twitter_accounts etc). When a user adds an existing account_id, I take care of merging the two different users rows, populating appropriately the account_id in one of the rows, then deleting the extraneous users row. I also migrate the existing data referring to the to-be-deleted user row to the one I plan on keeping.
This is a very, very nice project -- almost enough to pull me back from ReactJS back to AngularJS. Almost.
One question: they say it can be adapted to any Oauth1 or 2 provider, but doesn't the Oauth 2 provider have to support the Implicit Flow for this type of client-side app to work?
If so, is it true that Github doesn't support Implicit flow? (this is what I've read, and I've not found much on the web otherwise about what exact oauth flows Github supports)
I just implemented a GitHub sign-in and it took me only 8 minutes because on the server it was mostly copy-&-paste of the Facebook sign-in and on the client it's just:
I may be paranoid, but is there any security concern about doing authentification on the frontend ? Wouldn't the user be able to see exactly what is going on and intercept some sensitive information ?
I'd say cookies have a greater risk of being intercepted and hijacked than a token-based system.
But every implementation has flaws even if the underlying concept has been vetted. But if you're protecting sensitive information, it's always good to hire a security expert to test your systems.
I tried implementing a token-based authentication system, and it worked fine for a while. Then we added a subdomain (login.mysite.com) for registering, and it all went to shit. They don't share the same localStorage, so keeping the tokens in sync can be tough.
Does it have to be a subdomain? Few people pay attention to whether they're logging in to login.mysite.com or mysite.com/login The few times I've tried to guess a web page's login address, I've tried both a login subdomain and a login directory.
How easy is this to use without AngularJS? Additionally, if not, does anyone know of any alternative JS (or perhaps Python) libraries for what Satellizer does?
Satellizer is tightly coupled with Angular so I don't think there is much sense in using it without Angular. You can certaintly take server-side examples and re-implement satellizer.js in pure JavaScript but that is going to be a lot of work! The closest non-Angular alternative that I know of would be Torii (https://github.com/Vestorly/torii/)
It seems like a lot of this heavy lifting is left to api / backend implementors and is not explicitly addressed. I don't think that is a short-coming of the module but perhaps some additional documentation on best practices could be helpful.
I have considered Play Framework and Dropwizard. Play it seems is better suited for Scala language and I don't know much about real-world usage of Dropwizard. Between Struts and Spring, Spring seems to have a more active community. I haven't done anything with the Java example yet so Spring can easily swapped for something else if you think that other framework is better. I am not a Java developer so I need someone's help on this one.
So, how would this work if I'm using Python-Social-Auth as the provider as an interface to Django?
Most sites implementing social auth don't do it in the client directly, but as an interface to the oauth and then just trusting that authentication as canon, while simultaneously invoking a non-oAuth login() method at the tail end of the oAuth login. Not sure how this relates directly.
That said, this is a FANtastic, and very necessary module, and hopefully it covers what I think is the most common use pattern.
Satellizer is designed to be used without auth libraries such as Passport (Node),
OmniAuth (Ruby). On Python-side all you need is the requests library. It is so by design to avoid relying on third-party libraries. Additionally, if I were to implement it with a server-side auth library there is no choice but to use full page redirects, i.e redirect to Facebook, authorize the app, redirect back to the app.
[+] [-] filearts|11 years ago|reply
There were three major challenges for me in my implementation and I'm wondering how these could be addressed with Satellizer:
1. Anonymous content creation that can be attributed to a user upon sign-up or sign-in. On Plunker, anonymous users can create 'plunks' that will then attributed to them if they decide to register. This is important to allow streamlined user acquisition.
2. Account merging when someone accidentally creates two different user accounts with different social identities. This gets weird when anonymous content creation is involved since someone could create content while signed out and would need all that content re-attributed when they sign in.
3. Multi-provider authentication. In Plunker, certain features will only be available if the user has linked (for example) Dropbox. This means consumers of the api need to be able to add / remove social identities to / from users.
Hope to hear how you might attack these problems with something like Satellizer (or other people's approaches that have worked).
[+] [-] ovidiup|11 years ago|reply
In my app I maintain a users table that has columns (google_account_id, facebook_account_id, twitter_account_id, etc), pointing to individual rows in a separate accounts tables (e.g. google_accounts, facebook_accounts, twitter_accounts etc). When a user adds an existing account_id, I take care of merging the two different users rows, populating appropriately the account_id in one of the rows, then deleting the extraneous users row. I also migrate the existing data referring to the to-be-deleted user row to the one I plan on keeping.
[+] [-] lynndylanhurley|11 years ago|reply
https://github.com/lynndylanhurley/ng-token-auth
ng-token-auth comes with a Rails gem, and it's configurable to work with almost any API.
[+] [-] eric_bullington|11 years ago|reply
One question: they say it can be adapted to any Oauth1 or 2 provider, but doesn't the Oauth 2 provider have to support the Implicit Flow for this type of client-side app to work?
If so, is it true that Github doesn't support Implicit flow? (this is what I've read, and I've not found much on the web otherwise about what exact oauth flows Github supports)
[+] [-] sahat|11 years ago|reply
I just implemented a GitHub sign-in and it took me only 8 minutes because on the server it was mostly copy-&-paste of the Facebook sign-in and on the client it's just:
Thank you. I like React too so perhaps someone could implement something like Satellizer that integrates with React.[+] [-] jgrowl|11 years ago|reply
It looks like there is a good amount of config for handling different providers. Have you check out OAuth.io and its opensource core oauthd?:
https://github.com/oauth-io/oauthd
https://github.com/oauth-io/oauth-js
It's a simple node app and js sdk that lets you handle providers in a standardized way.
I created a ruby omniauth strategy that simplifies multiple provider support on the backend. A similar approach could be applied to any language:
https://github.com/jgrowl/omniauth-oauthio
[+] [-] JonnieCache|11 years ago|reply
[+] [-] evilsnake|11 years ago|reply
[+] [-] dmix|11 years ago|reply
http://self-issued.info/docs/draft-ietf-oauth-json-web-token...
Additionally, there are quite a few benefits to using Token auth over cookie-based auth as well, such as not having to worry about CRSF protection:
https://auth0.com/blog/2014/01/07/angularjs-authentication-w...
I'd say cookies have a greater risk of being intercepted and hijacked than a token-based system.
But every implementation has flaws even if the underlying concept has been vetted. But if you're protecting sensitive information, it's always good to hire a security expert to test your systems.
[+] [-] skybrian|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] oatmealsnap|11 years ago|reply
[+] [-] jnbiche|11 years ago|reply
[+] [-] MrBuddyCasino|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] gt565k|11 years ago|reply
[+] [-] zo1|11 years ago|reply
[+] [-] sahat|11 years ago|reply
[+] [-] pyre|11 years ago|reply
[1] https://github.com/simplabs/ember-simple-auth
[+] [-] fudged71|11 years ago|reply
[+] [-] sahat|11 years ago|reply
[+] [-] pingburg|11 years ago|reply
[+] [-] filearts|11 years ago|reply
[+] [-] nobullet|11 years ago|reply
[+] [-] sahat|11 years ago|reply
[+] [-] kclay|11 years ago|reply
[+] [-] datasmash|11 years ago|reply
[+] [-] motyar|11 years ago|reply
[+] [-] bmelton|11 years ago|reply
Most sites implementing social auth don't do it in the client directly, but as an interface to the oauth and then just trusting that authentication as canon, while simultaneously invoking a non-oAuth login() method at the tail end of the oAuth login. Not sure how this relates directly.
That said, this is a FANtastic, and very necessary module, and hopefully it covers what I think is the most common use pattern.
[+] [-] sahat|11 years ago|reply