[FEATURE] Add 'Devise And OmniAuth' option

[JezC]

The authentication options are none, devise or omniauth. No fourth option for Devise with OmniAuth. I'll be adding OmniAuth multi to my Devise by hand, then. :)

[DanielKehoe]

I've written about this topic in my Rails Authentication with OmniAuth tutorial:

Devise provides authentication when a visitor registers with an email address and password. Devise can be combined with OmniAuth, using the Devise Omniauthable module. When you add the Omniauthable module to Devise, you can offer a user the choice of registering with an email address and password or using a provider such as Twitter or Facebook to sign in.

At first glance, it seems ideal to offer a visitor multiple choices. In practice, it creates confusion. Users frequently forget how they initially accessed the application, and they hesitate to use the application when they are not sure how they are expected to sign in. For the best user experience, limit the visitor’s choices. If your audience is Facebook users, and only Facebook users, use OmniAuth. If you need to stay in touch with users by email, for example, sending payment receipts or a newsletter, use Devise alone. You should only combine Devise and OmniAuth if there is a compelling reason to do so.

I'm open to adding a "Devise with OmniAuth" option to Rails Composer but I'd like to hear what the use case might be. As far as I've seen, many developers blindly use the Devise Omniauthable module when it really is not necessary.

[JezC]

Here's some very quick outlines of use cases. An example each for a basic Devise with either OmniAuth single or multiple validation. I'd be very happy if you can explain how to do these without Devise and OmniAuth. :)

Use case: Agencies and Company Clients using AdWords Tools
Feature: Some staff have AdWords Accounts, many staff can use company AdWords Management Tool
Background:
Many company vetted staff can use the AdWords Toolkit, only a few are registered with AdWords
Scenario: Initialisation of AdWords Toolkit
Given a registered administrator (Devise) for the company
When an AdWords Token does not exist for the company
Then the registered administrator can authenticate to AdWords (OAuth2) and obtain an AdWords Token for that company

Second Use Case: Applicant Identity
Feature: Users can present proof-of-identity with social logins
Scenario: Candidates for event are selected on the basis of likely match evidenced by activity on third party sites
Given a registered user (Devise)
When a registered user claims a (Github, Stack Exchange, LinkedIn, Facebook, Twitter - OAuth2) identity
Then the user can opt to authenticate to provide evidence that they are who they claim to be

These are two examples over the last year or so, that I know about. Both have a requirement that many users register with a local username/password, but can provide additional proof-of-identity from one or many third party sources - which may be usable to validate further activity. In the first case, authentication is mainly controlled by Devise, but an identity can be optionally tied to AdWords for registrants with specific roles, and a valid token must be claimed by one of these special sets of registered administrators for a company, and only Google OAuth2 validation is required.

[DanielKehoe]

In the first case, I believe you would use Devise with the AdWords API (google-adwords-api gem).

In the second case, if you are looking for evidence of activity they are a person with an established social network, I think you'd use Devise plus one or more gems for the social network API, like a Twitter or Facebook gem, because you'd want to see how many friends or posts or date the account was established.

In either case, you're looking for more than authentication. No wish here to be contrarian, just want to see the justification for the effort required to implement and maintain the additional feature.