0

The most known SSO workflows require the Identity provider to provide the login page/form, for example Google's Authentication for its services.

An example for that is the: Simple SAML SSO Workflow

But in my case, I have a bunch of apps that each has its own login form. Therefore, having to perform a GET request to fetch the common login form breaks the UI experience. In my case I already have implemented forms for login.

Is there a workflow that will allow me to maintain the login page but still have a common method for SSO/common authentication mechanism?

An approach to this problem is double auth:

I mean both apps and user have credentials therefore during login I just send the app credentials, alongside the user one and I get a common bearer token. But I have apps that are completely in Javascript or in Android, so app credentials may be shipped to the end user as well.

Is there a known "battle-tested" mechanism to allow me a common authentication over Http without having to provide a common form?

1 Answer 1

0

One of the key features of SSO is that the service provider (you) never see the user's credentials for the identity provider (e.g. Google). Indeed, for many identity providers it is a breach of the terms of use for a user to provide their credentials to a third-party site (yours). Not only is it inherently dangerous for you to get to see my Google credentials (after all, with those you can get access to far more of my life than you have any business seeing), it is dangerous for the identity provider to "train" users that it's OK to enter their credentials on third-party sites (that's how phishing attacks happen).

There are other reasons why using your own login page doesn't work for SSO. For one thing, maybe I'm already signed into the identity provider and nobody should be collecting my credentials at all! For another, the identity provider always must ask me (the user) for my consent to share any information with the service provider (you); after all, Google has no way to know if you're really trustworthy, certainly not whether I think you're trustworthy, and any site or app can set itself up as an SSO service provider. Finally, maybe your login page just doesn't handle my credentials! What if I authenticate to the identity provider using MFA? Using a TLS client certificate? Using a FIDO2 / WebAuthN hardware token? Using Kerberos/Active Directory? Using a different SSO identity provider such as Okta?

Redirecting users to the IdP's login page (via redirecting them to the browser, if needed) and then back to your site/app isn't going to ruin your UI experience. People are used to it; that's how SSO works, and everybody knows to expect it. In fact, I'd be extremely suspicious of any site or app that tried to collect my credentials for a third-party site or service directly, and probably report it to the browser maker / app store as potentially malicious.


Now, with that said, you can of course support multiple login forms: one for each identity provider (their own forms, not yours), and if you want, you can also act as your own identity provider (collecting credentials and authenticating users against your own database) which of course will use your login form. Some people prefer the latter; maybe I don't want Google knowing that I use your site, or I want to be able to share an account with a trusted other person (e.g. my spouse) without needing to share my whole Google account. You don't have to support local authentication if you don't want to, of course; SSO works fine, almost everybody will have at least one of Google, Apple, or Microsoft accounts, and it saves you needing to securely hash and store credentials, handle password resets, handle MFA, handle credential stuffing attacks, etc. Authentication is hard; it's valid to ask somebody else to take care of it. Just don't go trying to collect the credentials for some other site yourself.

1
  • But I can somehow depending the application to have the IdP login page to display differently. In my case I have some B2B users and some B2C users. B2B Users use many apps (various panel and profile systems) but B2C ones use only a single app. All apps are owned by me therefore, I have no need for OAuth. I want the client to use local auth of the specific app without knowing that I use IdP. Mar 14 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.