I am thinking of adding an option to allow members to log into my club member’s area using Google+ (and perhaps other OAuth2 based logins as well).
I can find instructions on how to set up the login process but can’t find anything on how to identify which member is trying to log in. Without knowing that the person trying to log in is a member and which member they are the actual login processing is useless.
Does anyone have any thoughts on a field that the Google+ login provides that uniquely identifies a person that they would be able to provide in advance to link their login to their membership if they were to decide to use the Google+ login? The only fields I can see that are returned are name and email address and neither of these uniquely identifies a member as we have members who share an email address as well as several pairs of members with the same names.
What I can tell you about Discourse and how it implemented it, is they use email address. The email address you use with Google+,LinkedIn, Facebook, Github, must match the email address of your account on Discourse. If one isn’t found, it takes you through the account registration process, otherwise, it logs you in.
I can’t use email address for this as in some cases up to five or six members may have the same email address and there are a lot of instances where two members share an email address.
Not all families have separate email addresses for each family member.
Unfortunately, I’m not sure those logins would be beneficial to you then, or any OAuth implementation for that matter. As all of those other services require a unique email address to be associated to an account, that is how they determine your account…
Short of providing the user with a list of users who are associated to that email address (so they can choose which to log into), I’m not sure there is a solution for you since email isn’t unique.
Even that wouldn’t work even for my own login where the email address in the database is unique given that my Google email address is not the one I normally use for anything other than as an emergency contact for my hosting provider.
Perhaps if I add an extra field to hold the Google email address for those members who want to be able to logon that way - so then I just need to ensure that field is either blank or unique if not blank.
In the end I decided that there is no way to be certain of who it is trying to log in unless they confirm who they are as a part of the first login by entering their member number and password - which mostly negates the reason I was looking into it in the first place. So looks like it isn’t worth proceeding with.
I was hoping to find a way that members can identify who they are and log in where they are unable to obtain a password due to their email provider refusing to deliver the email they requested with the link to create a password.
Tangential, but something to add to the usefulness / not usefulness of SSO type setups - I recently (in the last year, anyway) had a client project that had some SSO services, and they were having a lot of trouble with people logging in via Google, I think maybe FaceBook, I forget - anyway, via other services. Researched the problem. Turns out that they disabled email verification a long time ago, and since those services are using email to tie to the right user account, if the user account isn’t using a valid email + the same one that their social account it using, it was an issue.
Talked to some of the sales reps that are getting people signed up for this service. Apparently they’re telling customers that "it doesn’t matter if you use a valid email, just put anything in this spot that has an @ symbol in it.
