Add support for RESTful JSON APIs access tokens and OAuth2.0 For Login

[fzagarzazu]

This commit adds a new submodule feature 'access_token', it is intended
for RESTful JSON APIs, it allows rich client-side applications to use
access tokens to communicate with the backend server.

It also adds support for OAuth 2.0 For Login - Implicit Grant Flow -.

[kristianmandrup]

I wonder why this has not yet made it into sorcery!? I really need it for use with Ember ;)

[patrickdet]

Highly useful. Token Auth would be a great addition to sorcery. /cc @NoamB

[kristianmandrup]

I have a recent fork where there is support for token auth (from @fzagarzazu) and also better mongoid generators.
The TokenAuth modules look really nice! Thanks to @fzagarzazu :)

[fzagarzazu]

Hi,
@kristianmandrup great, it would be nice to include your mongoid changes to this pull request.

Ps: I will see if I can publish a simple working demo this weekend.

Regards,

[Emerson]

+1 for this.

I also need this functionality for an Ember project. Seems like more of a core feature than some of the other stuff already included in Sorcery.

[mrcwinn]

Also badly needed to simplify an Ember-Rails project. Excited for this pull request.

[anthonator]

For those of you who need to add OAuth provider capability to your API you can try the doorkeeper gem. I've used it in the past and it works well.

[grossadamm]

Did you get doorkeeper integrated with sorcery? I'm having trouble with having doorkeeper use resource_owner_from_credentials and authenticating that against sorcery.
login(params[:username], params[:password])
gives
undefined method login' for #Doorkeeper::TokensController:0x0000000302d1d8`
Not sure what I need to include or where...

[anthonator]

This is what I have in initializers/doorkeeper.rb

resource_owner_from_credentials do |routes|
  User.authenticate(params[:username], params[:password])
end

[anthonator]

I also have this is my API controller

private
def current_user
  @current_user ||= User.find_by_id(doorkeeper_token.resource_owner_id) if doorkeeper_token
end

[grossadamm]

thank you very much! It works perfectly now :).

[kirs]

Could we use change method here?

[fzagarzazu]

@kirs sure

[lessless]

@NoamB is sorcery abandoned? :(

[NoamB]

@dirty-hippie I'm not maintaining it, but it has a new maintainer - @kirs , so no, it is actually more active than it has been in a long while... :)

[jamezilla]

+1

Seems kind of critical to staying relevant in the mobile-first world.

[anthonator]

👎

Sorcery's responsibility is first and foremost managing user credentials. API authorization has nothing to do with managing credentials and is beyond the scope of the project. There are other gems that do a very good job of providing this functionality and are relatively easy to integrate with Sorcery. I think the Sorcery community would be better served with some wiki articles rather than implementing this. Otherwise I'm afraid we'd be adding bloat and diluting the maintainers resources crafting a solution for a problem that has already been fixed.

[jamezilla]

@anthonator I'd urge you to actually a look at this pull request. It seems like you saw "OAuth 2" and imagined something else. This pull request is fundamentally about adding a token-based authentication module to sorcery. You might argue the merit of the actual implementation, but I don't think this constitutes "bloat" any more than any of the other modules in sorcery. It is a legitimate strategy for managing user credentials.

Token based authentication has a lot of advantages over cookie-based authentication. Have a look at this article for some examples:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

I'd also like to point out that OAuth and OAuth 2 are fundamentally about authentication. They also provide some authorization mechanisms, but you don't have to use them at all. Supporting both authentication mechanisms in sorcery seems reasonable. If you disagree then maybe you ought to lobby to have the entirety of the external module and associated code ripped out. Personally, I could get behind that as part of a larger discussion of breaking up sorcery into a more modular set of gems (e.g. sorcery-core, sorcery-oauth, sorcery-basic-http-auth, etc). That would help slim down the gemspec dependencies, which add a lot of bloat when you're not using big swathes of the framework.

[anthonator]

@jamezilla What I don't agree with is turning sorcery into an oauth2 provider which is the impression I got from reading through this PR. After reading through the documentation in @fzagarzazu's fork I'm still under that impression. It's already been done, very well, to the spec, and is easy to integrate with sorcery. If I misinterpreted this I apologize.

[slava-nikulin]

So, why this request was not accepted?

[Ch4s3]

@slava-nikulin it got caught up in a rollover between maintainers in 2014 I believe. If @fzagarzazu wants to rebase it, I can take a look.