Omniauth for the consumers

[afeld]

So earlier this year when I started working on OAuth consuming for Jux, I chose oauth-plugin over omniauth because a) at the time we only needed authorization (as opposed to authentication), and b) oauth-plugin handles the persisting of tokens for us, which we can use for API calls.

Since then I've submitted a few patches to oauth-plugin, but it seems like an endless struggle to keep up with the constantly growing number of OAuth providers. It seems especially silly, since the folks at Intridea are already doing so.

While the two projects have slightly different goals, it seems like there's a lot of overlap functionality that could be shared and benefit both areas, much in the way that ActiveModel was abstracted from ActiveRecord and is now used in many non-SQL ORM's.

My initial thought is that oauth-plugin's consumer functionality could be largely handled by omniauth, and then just do the persisting of the tokens after the OAuth sequence is complete. I like that oauth-plugin doesn't assume it's responsible for user authentication, so I need to make sure that's possible while using omniauth under the hood.

I really just wrote this down to solicit feedback - will probably start digging into the code soon. I'm hoping @mbleigh and @sferik will chime in with their thoughts, too :-)

Thanks!

[afeld]

@pelle @mbleigh @sferik any thoughts?

[mbleigh]

It seems to me that oauth-plugin is two projects in one: a provider and a consumer. The consumer side essentially feels like an OAuth-only version of OmniAuth. My vote would be not to have the consumer side powered by OmniAuth but to remove the consumer side and either simply deprecate it or put it in its own project to grow separately.

That being said, I've never used this library so I should have no influence on its direction.

[afeld]

oauth-plugin is a value-add over omniauth on the consumer end in that it automatically persists the token and provides a [SERVICE_NAME]/client/[ENDPOINT], which takes out a lot of boilerplate if it's being used to interact with multiple APIs. Very good point that acting as a consumer vs. a provider are two very different use cases, though. Here is my ideal landscape:

• omniauth: handles authentication and/or authorization
• (project 1): persists tokens received through Omniauth, and provides a consistent API wrappers and optional controller endpoints for accessing via the client
• (project 2): an OAuth provider

[pelle]

I have on my todo list to split the oauth plugin into 2 separate projects.

But OmniAuth does seem to have a well maintained list of providers.

I haven't looked at home OmniAuth, but it seems like it would be useful to be able to add omniauth strategies to the oauth plugin configuration.

[carlosramireziii]

@pelle Have you gotten a chance to make any progress on splitting this project into separate provider and consumer gems?

[localredhead]

@pelle also interested in a separation of provider/consumer gems. We use Omniauth as well as oauth-plugin and it would be nice differentiate.

[pelle]

I am afraid I don't think I have time for this for a while. I'd welcome anyone to take it on and give commit rights.

[pelle]

It should be pretty simple to split up. If I do it I'd like to remove OAuth1 support as well as new apps shouldn't be created with OAuth1 anymore.

Any objections to this?

[afeld]

Sounds reasonable to me.