Equivalent scrapbook

…article on Omniauth and password login best practice

(in this question I'm asking the same thing I'm asking here http://stackoverflow.com/questions/7247145/what-is-the-omniauth-email-pasword-registration-best-practice/7255898#7255898) and http://railsforum.com/viewtopic.php?id=45315)

what is the best practice to combine facebook sign up (let's say I'll use Omniauth gem) and email+password sign up. I saw few blogs, saw the Railscasts, I know everyone is using Devise gem with Omniauth. But I'm looking for some different perspective.

This is how I saw it's done in most examples on the web

Alt text

basicly when you signup with email+password, you are creating row directly to User model (not touching the Authent. model) and when signing up with Omniauth, than you are creating new authentication that communicates with User model.
And basicly on next login you are doing something like this :

Alt text

if (user.password == 'xxx')
login
elsif user.authentication.uid == 'xxx'
login
else
'hello signup !'
end
so you are swiching between 2 models, and raping (sorry for the term) the User model witch should hold only user info
tihs is the solution, in a way, I think is correct (from my experience and discussions with my colleagues but I'm still not 100% sure this is the right answer)

as you see even the user+password is going trough Authent. model, that means the site user+password is acting as a provider on its own
so to be absolutly correct it should be look like this

Alt text

scenario 1
signing up with FB: you save FB uid and authKey to authentication table, then create user
scenario 2
signing up with password: you create new row in AppPass table, then you create row in Authentication table (as a access to provider witch is actually your app) and than you create user
Why?
because now when user logs in, is always going trough Authent. model, not making condition between 2 models (the Authent. and the User model)
now can anyone please tell me, ...is this a good approach or is there better way of doing that ?

subquestion: is there any gem

Answer

I posted this question on several forums, without no answer (at first I though everyone is ignoring this question but you will further see why my scenarios aren't so straight forward). I kinda dig in to these problematic more deeply an done some research on my own, these are the conclusions.

The problem is that I'm trying to combine my authentication functionality with site login/signup functionality, witch are two different behaviors. At the end of the FB signup with omniauth, you will have in your Authentication table the facebook uid and that is all that it takes to back login to FB for next time (of course you can store other info (like email) ... but logicly they are more users attributes and should go to user table).

note: its ok to  store user information from provider, in Authentication table, 
but if you want to work with them you should  copy these informations to Users table

When you are signing up with email/password solution, you are writing information that define User on your site. (Authentication is just pointing to User) If we wanted to do password signup trough Authentication table, we would have to store the username & password inside authentications table, and this way merging User model and Authentication to one model. It will be much uglier solution, not talking about problem how to store multiple rows to one user. Also you the Authentication or Oauth are synonyms for "accessing your application trough other site" ( watch these oauth2 videos if you cannot imagine it), yet with normal login you are accessing the site directly.

The only way around this problem is making a small app, that will handle the email/password or the user/password signup, generate password provider UID, and write those data to Users table, and than with our main applycation we will request trough omniauth to access the miniapp and store the UID in authentications table.