Adding SSO to existing username-password auth

[colinw]

Hello,

I didn’t seem to get much help from the support ticketing system, so I’ll try here.

Here’s a brief description of our current implementation. We have a React app with a custom UI for login, with a Java backend API built with dropwizard, and are using Username-Password-Authentication. We use the auth0-js library in our React app for user sign-ups and to trigger password changing emails, and we use the Auth0 Java library in our API for authentication. We also manage a user’s session (more or less) in our own database to give us added flexibility in managing our permission sets for access to parts of our UI and maintaining affiliation to which of our clients a user belongs. So, a typical flow would be, after sign-up, the user enters their credentials and our API sends the authentication request to Auth0, we persist the returned access token, tied to the user in our database via the Auth0 user_id, and use said token as well as other properties in our database to determine what our UI should show and authorize requests to our API.

All that seems to work just fine, but we have a newer client that wishes to use their adfs connection for SSO with our application and I’m not sure how to go about adding it in to our implementation, and, to be honest, I’m not entirely certain if our implementation is ideal to begin with. The desire is to support both Username-Password-Authentication and SSO for our clients while also maintaining the current flexibility of managing our user’s permissions and client affiliation.

I’ve scoured all over and read a bunch of documentation over the past few days, and I feel like I have pieces of the puzzle, but can’t seem to get them to fit together. If some kind people could provide me with some guidance and/or resources, I would greatly appreciate it.

Thank you!

[markd]

Hi @colinw,

My answer is probably going to be a bit vague, but it is useful to think of an Auth0 hosted database connection as “just another identity provider”, and you can have as many different identity providers as you like, which you can mix and match with your apps in whatever combinations make sense for you.

“Auth0 is a programmable hub sitting in between all your identity providers and all your apps / APIs.” – Me, c. 2017 - 2018

When a user logs in from an enterprise or social identity provider, an Auth0 profile is still created for them, and that profile can include user_metadata and app_metadata just like a user in an Auth0 database connection. Such a user will still have a user_id, though it will look a bit different:

  "user_id": "adfs|john@fabrikam.com"

[colinw]

Hey @markd,

Thanks for your reply! My thought processes before were a little misguided and sending me down the wrong path. I think this has helped me to reframe my mindset to connect the dots better, and I have a better idea as to how to approach this now.

Thanks again!