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).
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.
While you gloss over it a bit, the 'migrate the existing data' part is a challenge of its own because it means that suddenly the auth component needs to either know every place where a user<->content association is made or you need some sort of queue set up to publish user merges to all parts of the app in a reliable and durable way so that they can process the migration themselves.
I would say that this is also a UI concern and therefore something that a service like this would need to handle because it should _not happen automatically_. When a user conflict is detected, the user should be able to make a decision via appropriate UI. We would not want two accounts being merged simply because of some degenerate case where someone logged into their account on a borrowed computer.
https://github.com/intridea/omniauth/wiki/Managing-Multiple-...
Use what works for you obviously, but this would have the benefit of scaling easier if you end up ever needing to support additional providers.
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.
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:
$authProvider.oauth2({
name: 'github',
clientId: 'xxxxxx',
url: '/auth/github',
authorizationEndpoint: 'https://github.com/login/oauth/authorize',
redirectUri: window.location.origin
});
>I like React too so perhaps someone could implement something like Satellizer that integrates with React.
Indeed. And such a project could still make use of the server code of Satellizer, I'd imagine.
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:
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.
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.
https://github.com/omab/python-social-auth/issues/68
That said, I'm working through piecing that together with satellizer, and I wanted to give you a huge thanks for including the server examples in so many languages, which ought to be of use.