I have two web applications. Today they both have their own way of authenticating users and storing their credentials. Some of my users use both applications -but their usernames/passwords may be different in each application.
I would like to introduce a single-sign-on solution for these application so my users only need to worry about a single username/password.
What is the best way to migrate these applications into an SSO solution? Specifically, how do I securely associate a user in Application A with their respective user in Application B?
For one user, since the usernames may be different in each application, I don't think I can run a script a 'merge them.' I would prefer the users elect to merge their accounts and prove they own both accounts. Can OpenId Connect help with this problem? After authenticating with App A, I can ask if they would like to pair App B to their credentials in App A. They would then be redirected to authenticated to App B. If successful, it would redirect back to App A with their App B username in an OpenId Connect token. The SSO solution would then store their App A and App B credentials together as a pair. In the future, local app sessions with each application can still be creating using their legacy username but the user only deals with a single SSO username going forward. Thoughts? What are other approaches to solving this problem?
I'm not concerned about the cookie/cross-domain issues. I'm most interested in how to reconcile the usernames across both systems.
Related
I apologize if this has been answered, but I have been searching for hours, and still don't quite understand. This is a specific question, and not a "which is best" question.
Specific questions are in italic.
I have created a RESTful API, which was at first meant to be completely open. However, the organization has now decided to create a first-party mobile app to consume and (to some degree) update the data.
I am investigating authentication frameworks (oAuth2), and was not sure if oAuth2 was the correct way to go to meet our goals. And, if it is, which Authorization Grants applied to which set of users.
Our goals are:
To allow users to login and create accounts in the first-party app, entirely through oAuth 2 providers (twitter, facebook, google). These users would have access to the greatest set of data via the first-party app.
Assign different roles to the users (admin, moderator, etc).
Allow other applications to register, receive token credentials, and have limited write access or expanded access to the data. This would open them for creating third-party apps or research systems.
Finally, we would like to keep some of the data completely open, with no authentication needed.
So, am I right in assuming that we want to setup an oAuth2 *Server* (Authorization and Resource Server)?
If so, which Authorization Grants apply to the above situations?
One last question: For users using the first party app, would the app be responsible for logging them in and keeping their access credentials? The API server serves NO html, and is 100% RESTful. Does it need to serve login forms?
If you need to both authenticate and authorize users to your API based on various OAuth2 social logins, you do need some kind of API server or service where you can define your users and groups/role and the scopes that are available to users based on your rules.
Some cloud-hosted options for this are:
Auth0
Firebase
If you integrate with a service such as the ones above, you can let the service take care of authenticating users and just make sure that every user call checks against the service first for permission before it goes ahead and does anything.
We have a need to secure our .net web api using open id and OAuth standards. IdentityServer 3 is perfect for us as we have to use our existing user store.
Edited for more clarity:
Our company services multiple customers. Each of our customers have their own database. In our home grown client application when a customer user enters their user/password, we do a lookup to authenticate and that also determines what backend database the app connects to.
We now have a need to allow a couple of trusted partners to access our database resource for specific needs. We have created a web api for them to make specific calls. The web api needs to know what customer the partner is making the call for. The partner is calling the api from services on their side so there is no user interaction.
I am trying to determine the flow to use to accomplish this. I found some pretty good info on flows at https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c.
If I define the client using the Client Credentials flow, I don't know how for them to pass the customer they are making the calls on behalf of. I don't think we want to definate a "Client" for every partner/customer combination, but is this the correct way?
What we had thought of initially is to give an additional user/password or secret key that would tell us the customer, but I am not sure what "flow" for the client would allow this.
Any help or direction would be greatly appreciated.
In case this helps anyone else, we decided to go with a Hybrid flow for these types of requests. We considered designating a service account (user/pw) for each of our customer databases that would give this trusted 3rd part access to them by requesting tokens with the Resource Owner Password Credential flow, but decided against it. We decided against it for all the reasons the standards say not to use it for this use.
If the 3rd party wants to interact with us on the behalf of one of our customers, then they will need to build the UI on their side to redirect to us for user/pw authentication and consent.
I have an intranet application which I want to simply authenticate the users by their network ids. The users are considered trusted and I want to login the users without their interactions. In this case, which flow should I use?
I made it work with resource owner flow but I think this approach is not good enough. If I use Implicit Flow or Authorization Code Flow, can I achieve the goal that the users do not need involved in the login process? Which means the users do not need to consent to the authentication requests?
Thank you!
Consent is just a client setting (RequireConsent). But it sounds like you also want something like Windows integrated authentication.
This makes me wonder if you need an extra token service at all - since you already have one (called Windows domain controller).
Few sites I've come across using either Google, Facebook or Twitter connect for login. Still they are asking for new password creation.
Ex: http://setapp.me/
Why user need to setup another password when the user is using OpenID/Facebook/Twitter connect?
One need I can think of: if the user disconnects the app from any of the above OAuth/OpenId connect services providers (Google/FB/Twitter/...), then as an alternative way for the user to login - as a best practice.
What they're doing is an incremental step towards federation, but not what I'd describe as a best practice. For apps that aren't ready to fully embrace relying on another service for identity it is still sometimes helpful to connect with identity providers to speed up the sign-up process. In other words, just as a mechanism for pre-populating the signup form.
However, if using it for sign-on, then having a local password is one more potential vulnerability. The reality is the vast majority of users just re-use passwords across sites. That password is only as secure as the weakest application that stores it. If one app is compromised and email & passwords recovered, attackers know that a good percentage of those are valid logins elsewhere.
Best thing to do when federating with Google/Facebook/etc is to not ask the user for their password at all. Trust the major identity providers to keep account information & credentials secure rather than take on that responsibility yourself and deal with the fallout if your app is compromised.
Lots of good reading here if you're up for it: https://docs.google.com/a/google.com/document/pub?id=1O7jyQLb7dW6EnJrFsWZDyh0Yq0aFJU5UJ4i5QzYlTjU#h.moajj1qnb85l
There are several applications that use your domain credentials for login. Eg: Custom Corporate apps. How do you ensure that such applications don't store your password?
The reason I am asking this is: If you are designing an app which does the same thing, how do you convince the user that your app can be trusted not to store the password?
If you really want the user to be sure your app is not keeping their password, don't use their password.
Microsoft Active Directory Domain Logon uses Kerberos. Kerberos is an SSO solution; an application may make use of a user's Kerberos credentials without requiring that the user enter their password a second time. The credentials obtained by the application may only be valid for as long as the user's Kerberos ticket - probably at most a week.
If you have a web application, it too may take part in the warm goodness via SPNEGO. You may have seen this in the form of Sharepoint sites that don't require a login if you are on the company domain.
If you have used standard AD-based Windows authentication they shouldn't have your password but they could certainly perform actions using your user context.
If you provide a username/password to login using standard Windows authentication then there is no way for you to be sure they haven't saved that.
If Windows auth issued login tokens that expired this might be a different story, but I do not believe that is how it works and certainly would still be useless with the second case.