Me and my colleagues developing an application (both web application and mobile app(iPhone & android)), which includes a login process.
Currently, we have our own login mechanism (where users have signed for an account on our app, and have stored their info in our Database). We are looking into integrating oAuth and allowing users to login with Facebook, Twitter, LinkedIn and Google.
Now, when the users logs with any of those, as I understand the login process occurs outside our application and basically only get permission to access their resources.
My question is this: through oAuth, how do we remember users? i.e., users who login have read /write privileges and have preferences. How do we remember those when they don't actually sign up through our app.. Can we store their email address in our "Users" table??
What are the best practices in such a scenario?
Thanks for any info you can provide.
Having built authentication databases for a few different OAuth-enabled web sites, I can say that I've learned a few things that you should keep in mind.
You should have a table of users for your site that is completely independent of which OAuth provider they used for sign-up/sign-in. This enables your site users to combine multiple accounts together under their primary identity on your site. (For example, associate both Facebook and Twitter with you.)
When you let a user sign up, you should get an email address from them. Whether you ask Facebook for it, or if you have to ask directly. This enables you to "upgrade" users later from depending purely on third party OAuth to setting their own password on your site. (You simply send them a link to your password reset page in order to get them started creating their first password.)
You don't want to use email address as your primary key. I'm not sure if that's what you're actually describing or not, but you really want them to have a local user ID that you use for maintaining their session, etc. You then associate their Facebook ID or their Twitter ID with that local ID, and use the correspondence between such identifiers to match up which of your site's users to consider logged in.
Related
I have an ASP.NET MVC application that is used by different customers. Currently the app is set up to use individual user accounts. I have built some authorization logic around that and would like to keep the logic unchanged.
I got a request that some of the customers would like to perform authentication for their users with their Azure Active Directory. I have uncommented the app.UseMicrosoftAccountAuthentication part from Startup.Auth.cs. I registered the app as multi-tenant in my AAD. I managed to get the whole thing running and users now have the possibility to link their accounts with AAD and use it for authentication.
However, I encountered a few problems I am struggling with:
In order for the user to link his account with AAD he needs to set up an individual login/pass account in the first place. How can I avoid that? I want to have the users either authenticating with login/pass or with AAD, not both at the same time.
I have no control over which account the user uses to authenticate. Let's assume I expect the user to use an account in domainx.com, but if they link domainy.com account it will still work. I need to have some kind of way to compare the expected domain with the actual one that comes back from AAD. How can I do that?
One of the ideas to tackle the problem was to have a customer admin create the user accounts for them. The issue is that in AspNetUserLogins I need to store the user's AAD ID, not the email. How can I query AAD to check the UserID based on the email?
Note: This is the first time I'm trying to implement a social login API, so thanks for bearing with me and helping me out!
I am developing a web application and I have a login and registration system already developed. Now, I am thinking of adding Facebook and Google+ login - with a backend. I went through their docs and other tutorials and they require to implement considerably a lot of things.
But, since I have a registration system already, I thought of doing something like this:
Have the social login buttons on the login page.
When the user clicks on a social login button and authorizes the app, the user data is returned from Google+, for example.
Now, instead of proceeding with the OAuth procedure like getting the user ID, secret ID and contacting their server from my server for token verification and getting data, is it possible to just use the data returned (after the user authorizes) and do the normal registration with the registration system that I already have?
These are the advantages that I see in doing this:
No need of extra code or database fields like token ID, etc.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
I know the advantages are the same when following the full OAuth2 implementation, but what difference does it make?
Now my questions are:
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
The system proposed by you has certain flaws, especially security related flaw. I would give you to the point answer:
You will send data from client after getting it from google+ or other provider and use your registration process implicitly.
This approach is wrong as I myself as an attacker can send you the data from google+ using my clientid for an app. Will you register or login using the info I am sending? I can pretend to be anyone in your system if you do that.
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
No. (see the reason above).
No. You won't be losing advantage as you already have system in place. Most of the sites have a system in place for normal registration. They give oauth login by leveraging it. Some will say that the password is cumbersome or such, but all famous sites provide login and password including SO.
Now the question comes, how to simplify the oauth system given that you already have a system in place.
I recommend this(I would assume Google as a provider) flow with things starting with dot are what you need to do:
You have a Google login button.
User click on Google Button.
The User is redirected to the Google site.
The user gives you permission.
Google redirects and give you a token.
You can now send info and token to your server. (You need to send only token as backend will get info. Otherwise, a user with valid google+ token for your website can send you any info).
Backend verify token and match that "aud" is equal to your client id. Or it can happen via a library. You will need to give only your client id.
Backend get profile info from token in case of Google+(Name, email) while verifying which you can store as part of your registration process or login process if that email already exists. You can store google id of user also. This is useful as some provider like fb don't always provide email for every account. (For some fb don't give email but for majority of cases it give you the email.)
Backend send back session info or jwt token or any other time bounded process which tells that the user is login.
Your user can login via email also. If he isn't already registered then, then he will need to register. Otherwise, using forget, he can set password or from accounts settings he can set password.
You also need to be careful if the same user is connecting via a different provider, he need to have the same account in your system which you can handle via email.
Kevin,
Authentication is a complex procedure involving lot of measures to ensure security. Hence Web-application/ App developers, delegate this critical piece of work to Identity providers like Google, Microsoft, Facebook etc. These Identity providers are trusted by the app developers and more importantly the consumers trust them too.
Why do app developers provide third party/ social logins? Because, it gives the users of the app some advantages.
They don't have to create new account with the app and remember the new set of credentials. Instead they can use the same credentials they are using with the Identity provider, to gain access to the app. This is huge.
They don't have to trust the app completely, means how the sensitive information like passwords, security questions are handled in the app, as they are not providing any sensitive information directly on the app. Only needed public information is fed to the app from the Identity provider. This is huge too.
No need to worry about the system compromise and leak of sensitive information as all Open ID providers have better security policies in place. This gives consumers a high degree of confidence when using your system through third party logins.
"All the advantages you mentioned will be great for the app developers
at the cost of disadvantages to the consumers of the app."
Lets put the consumer disadvantages on the side and look at the advantages you mentioned:
No need of extra code or database fields like token ID, etc.
You still need code/setup to validate your own tokens. You have to add more logic to verify the external tokens, but the consumers will have the advantage of using the external providers like they are in any other application.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
This is little confusing as users may choose external provider, so they don't have to remember a new password. Also, the account validation process is different if you use external login vs id/password login. If you are willing to provide both, then you already have the system in place, to verify the account for external logins. Then your first advantage is void and you are better of using Open ID spec.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
This approach adds confusion to the flow for consumers. They expect to see a login screen from third party provider for authentication (when they click on google+ or FB), but instead they see your login screen.
Instead of cut short approach, it would be worth to use the complete flow. You might add more logic to handle the token verification with external providers, but, actual complex logic of token validation is delegated to the external providers. This adds no confusion to the end user and they can trust your application easily through social id providers. Even though, users can authenticate through social Id providers, it is always a best practice to have the profile object of that user in your system (without the sensitive information like password).
Since you have your own registration process in place, this may not be a huge advantage. But, please look into the open source implementation of any of the Security Token Service (STS) providers, to see if you can borrow some of the features for validation external providers.
Please let me know if you have any questions.
Thank you,
Soma.
I'm looking into creating a single-sign-on portal built in ASP.NET MVC. This single sign on portal should give users the option to sign in with their individual account (which should be verified against AD) or their Facebook/Twitter account. What I'm still in the dark about is if the application/authentication flow I came up with is actually feasible. This is how it should work:
User logs into the SSOP with his AD account (using a custom form where he enters these credentials). The SSOP verifies these credentials against AD and logs the user into the SSOP accordingly. The SSOP then offers the user to start any of the applications he has access to (based on his group memberships in AD). These applications are built by various third parties and are not all .NET based. Clicking one of these applications in the SSOP should log the user into this application using the credentials authenticated against AD that were used to enter the SSOP. I currently do not know how this should be done, e.g. by using claims or some sort of auth token? Obviously the receiving application should support whatever option we choose, which means we're looking for a best practice of some sorts.
The social login part of the SSOP should work somewhere along the following lines: The user logs in using his social account. The first time he does, he also has to enter his AD account credentials so we can link his social account to a specific AD account. Every subsequent time the user logs in with his social account the SSOP should log in the linked AD user. That way the SSOP always uses a valid AD account to authenticate to the applications it offers the user. This also makes it easier to administrate the user base since these are all stored in AD. The social login links and any other SSOP specific data is stored in a custom data store (MS SQL db).
I've been looking into the ThinkTecture IdentityServer, but have yet to figure out how it can be used in this scenario or if this scenario is even feasible.
So, the question basically is: is this authentication flow even possible or remotely best practice? If so, where to begin? And if not, what is?
According to this question: Architecture for merging multiple accounts and registering a user account
Various answers have said that using email is a good way of establishing correspondence between different accounts and then doing automatic merging for multiple account sign in.
However, twitter is a major provider that does not provide email through their oauth API.
How can we reliably and automatically establish a correspondence between a twitter account and for example Google, Facebook, Github... etc accounts? So that we can auto-merge those accounts.
I'm writing a library to help in this, so it's not really useful to say do it manually, since I would like to provide options.
There is no secure-way to automatically do it, I implemented an application with local account/Twitter.Facebook/Google and I didn't have other choice.
I suggest you to allow your users to register with one method (local account, Twitter, Facebook, Google...) and create a page in "My account" that allow them to associate other accounts.
In Twitter a user can be identified by either a name or a key, you have no way to know them unless you explicitly ask them to the user.
Moreover now in Twitter 1.1 you have to redirect your user to Twitter to approve your application and then you get the OAuth token and security key. As you can see there must be an interaction with Twitter, at least if you need to perform some restricted queries on his behalf (e.g. create a Tweet).
I've got a company web app. I have integrated it without much problems with Twitter.
This means, when a staff of our company creates a new product, it posts onto the company's profile on the Twitter web site as well.
However, Facebook is another story. Facebook encourages registrants to sign up as "individuals".
For example, on the registration page:
You are not allowed to put generic emails such as (support#company_email.com, sales#company_email.com)
You may not have the first and last name as a company entity. For example Foo Distribution or Foo Inc
Their automated system simply rejects any clever attempts to register as a "non-individual". With Twitter, it was a breeze. Since Twitter allows / encourages companies to register an account with them directly, and not as individuals.
Moving along on Facebook, I found out that I can create a 'page'. Which I can use for the company. It has the option of allowing other "individuals" to be admin of the page. However, this would mean that each staff would need a Facebook account.
I don't really like this approach, since some of our staff may be negligent with their Facebook passwords. I rather have our web app have one 'method' of accessing Facebook's API isntead, the way it is done with Twitter.
How else would you go about this?
I'd make yourself the admin of the page, install an app that you develop, and then let your users make posts to the page through that app. This way, you're controlling access to the page while letting your users still have access to it.
You'll need to use an offline_access-enabled access token for this to work continuously (permissions documentation), and if that token changes, you'll have to log in yourself and refresh that token (it can change when you change your password or uninstall/reinstall the app). Additionally you'll need a manage_pages permission, and you'll need to use the access_token for your page that you can find in /me/accounts to make posts to the page.