Currently I am developing an application with several access methods based on Laravel/Socialite, I want to allow users authenticate with facebook, twitter, google so far or creates it's own account by filling a form with name, email, password.
Routes
login/
login/facebook
login/twitter
login/google
Questions :
¿What is the best approach once the User data has been obtained from the auth provider?
¿How to handle a common data user storage?, I mean, I am storing only person name, email and avatar, but how about the token provided by the auth process.
¿How to handle when user log in with more of 1 providers with a same email address?
And how to handle when a user set password to his account created trough facebook?
I thank your attention .
Related
I have been trying to create an authentication in Laravel that is based on simple verification via an external services API key. The external API will provide me details like the username associated with the account a user should only have to supply an API key to login. No password, email, or username required.
Looking at Laravel's documentation it seems like using something like they demonstrate in the "Manually Authenticating Users" section may be most applicable. My problem is that this still appears to be based on a email + password credential model.
What is the proper way to modify/extend the frameworks authentication system to use an API key. If I use this manual authentication model I would be able to connect to the API and verify the user but I don't know the best way to modify it to accept an API key and username as the "credentials" for a new account (username would be coming from the API response data).
Suppose I have an application in which I have enabled (google) Oauth2 authentication but I want only a few business people can log in to my application with there specific email id and rest of the people can't. How Can we achieve this using Oauth2?
1.) Lots of people have a Google account and can authenticate with Google
2.) I want Only some of them should be authorized to use your app, which maybe deals with business assets
I suspect your requirement is:
Lots of people have a Google account and can authenticate with Google
Only some of them should be authorized to use your app, which maybe deals with corporate assets
In this case I would proceed something like this:
STEP 1: PREREQUISITE USER SETUP
Get a list of users and perform an Administrator Approval step to create them in your product database, perhaps with Name and Email fields.
STEP 2: INCLUDE THE EMAIL SCOPE DURING LOGINS
In the Google login redirect, use scope='openid email' so that you can identify the user via email after login. Allow users to successfully authenticate.
STEP 3: AFTER LOGIN PROCESS THE ACCESS TOKEN
You will then get then be able to get the user's email address from the access token (though you may have to send it to the Google User Info endpoint).
STEP 4: DENY ACCESS WHEN REQUIRED
If you can't find the email associated to the token in your product user data, present a Forbidden message to the user.
FURTHER INFO
See my User Data Write Up for further details on technical options. Note that I have not actually tested this with Google, but I have used the general approach with a few different systems.
I have a problem authenticating users in my banking application. I want super users to be created and authenticated using email. However, I want that normal users be registered and assigned account numbers. The normal users would then use the account numbers to login. How do you achieve authentication of these different kinds of users with different username fields in one django project.
I have tried overriding the USERNAME_FIELD to account numbers so that normal users would use that to login. It doesnt help to login normal users. For superusers, it prompts for account number when I run
python manage.py createsuperuser
Kindly assist in understanding how to handle this kind of custom authentication.
Django is ready to support your requirement. AUTHENTICATION_BACKENDS support multiple backend as list. For normal user you have to write custom backend and Add that in AUTHENTICATION_BACKENDS.
This link will help you.
I am adding a Login with Facebook button to my Larvel web app. Users can already register using an email and a password, So what I need to do is to give the users the ability to Login with Facebook, without having to register using Facebook from the beginning. I have already accomplished this, but I facing a security issue.
The authentication flow goes like this once a user cliks the Login with Facebook button:
Redirect users to facebook -> Users enter their email and password -> Facebook returns the user object back -> If the email returned with the user object exists in my database, log the email owner in.
Mostly you have already noticed the problem, but if not, consider this case:
If a user registers with their email in my application, and happens to not have a facebook account associated with that email, then anyone can register a new facebook account with that email, and then just simply log in into my application (Because that email exists in my database!!)
I have been googling this for quite a while now, and it seems like there's no one mentioning this problem, I am assuming this is because I might just be doing it the wrong way!, or maybe it's just done this way! Not really sure.
So, I am seeking guidance, how is this done right?
I'm trying to implement OpenID authentication for my site. Here's the scenario:
I want the user to be able to
login using just openId(user can just get verified by visiting openid provider. no need to create a custom account with email-password),
Via email/password (user has registered in site by filling out a form)
Attach open id(s) to his/her accounts (openids + email for one account).
Now I don't know what credentials I should store for open id. and not sure about the DB schema. Here's the database schema:
Table: Users
UserId => PK
... => Custom info. Not related to authentication.
Table: Authentication
AuthenticationId => PK
LoginId => (when custom site membership => email address) (when openId => openid unique address)
UserId => FK to Users.
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address)
Password => filled when using custom membership. empty when using open id.
Now when a user logs in, whether by using openid/custom membership, I just look at authentication table and look for credentials and get the appropriate user. If no users exist, I create a new user and add an entry in authentication table.
The main question: Is storing Provider and LoginId (see the above comments to see what is being stored in these fields) enough for storing openid authentication? Should I store any additional data so that when the user returns I can authenticate him/her based on my saved data?
Do you suggest any other (more efficient) approach to implement this?
Thank you.
Store the ClaimedIdentifier for the openid user--not the Provider address. The Claimed Identifier is what the OpenID protocol verifies is unique for the user and also potentially provides portability across OpenID Providers.
Also, because OpenID 2.0's Claimed Identifiers may be deprecated by OpenID Connect (an unfinished successor to OpenID 2.0), it may also be in your best interest to record the OpenID Provider Endpoint URI and the email address asserted by the Provider in the user record. For now, do not use these as part of your authentication flow, but by recording them, you'll be able to later determine which email addresses you 'trust' (i.e. suppose you decide email addresses asserted by Google are trustworthy) and allow the user to thereby migrate their account to an OpenID Connect one using that verified email address. This will also mitigate against the danger of your web site's Realm (usually http://yourdomainname.com) changing and causing all your Google's user Claimed Identifiers to change, which can only really be recovered from via their email address, tragically.
I also recommend you use different tables for the different auth types. There are a couple of advantages here. The most important one is that architecturally it makes it more difficult to have introduce a security hole into your web site that might allow someone to enter in (for example) an OpenID into the username field and a blank password and have it show up as a database match and login without any real authentication happening. Secondly, it provides a more flexible model in case you want to add a third authentication mechanism rather than making your 'Authentication' table grow horizontally for all users. For example, OAuth 2.0 and "OpenID Connect" will each probably introduce new types of authentication to your site when you add support for them over the years, and adding new tables to handle the new types of data seem to fit better.
We just store the openid claim url. You may want to request additional information from the provider such as the user's name. The most important thing is to separate membership and authentication.
Our schema was
Profiles
--------
UserId
FirstName
LastName
etc.
Users
-----
Username
Password
Profiles.UserId is simply a string property that stores either the users internal username or their openId claim url, depending on how they registered.
Upon successful authentication (either using an internal username/password or external provider) we just set their authentication cookie using either their internal username or their claim url. Getting the user's profile is then just a matter of finding the profiler where (UserId == User.Identity.Name).
This has the advantage that a user can choose to change how they authenticate at any point (perhaps switching to an internal account or using a different provider).