Got any SaaS SSO tips?

Has anyone here used SSO (single sign-on) with a SaaS app? I’m asking from either side - the SaaS vendor or the customer.

Is there any approach in particular that you’d recommend? Did you encounter any frustrations that could have been avoided with a different approach?

I’m keen to hear any tips about how you added SSO.

1 Like

(I assume when you say SSO you mean “users of other services - Facebook, Twitter, … - can login into your application”, not “I have 2+ applications and want to share users between them”.)

Use OAuth which is supported by everyone now. OpenID is out of use now.

The main annoying thing is that every provider has their own little quirks. However many libraries for OAuth support already deal with these differences, making them invisible for you.

I assume when you say SSO you mean…

Thanks for the answer. It helps to illustrate that simply requesting SSO is ambiguous.

Adding SSO to Feature Upvote is currently our most highly requested feature. I suspect different customers want different things which they are all calling SSO.

I wrote to a specific customer who has been asking for SSO to find out more about what they wanted. It turns out they want to be able to integrate our SaaS’s authentication with their existing Active Directory server using the SAML protocol.

The way we handled this at Roadmap was to have the portal embedded into their own app (web or mobile).

Maybe something you could consider instead of SSO @SteveMcLeod since we’re kind of on the ~same grand market.

Instead of handling authentication from our end via SSO, our users can have their roadmap and ideas portal straight into their web application, behind their sign in flow.

That was done to postpone implementing SSO as far as possible I must admit :slight_smile: Which we’re also starting to investigate. But at least we saved 1.5 year.

1 Like

Ah…that does sound like a much easier way to achieve SSO! A benefit of an embedded widget I hadn’t thought of before.

1 Like

By coincidence, this is in my TODO list as well. I just fired a short email to my clients security folks to ask them what are the required steps.

My understanding the steps are as follows:

  • Trust the AD Identity Manager (essentially obtain its URL and the certificate)
  • When an un-authenticated user comes to your page, form a SAML request and redirect to AD page, where the user will be authenticated one way or another, and the SAML will be enriched and signed.
  • AD then redirects the user back to the same page on your app, except it now has user properties. (This part is not 100% clear to me - how that XML is passed back?)
  • Now you verify the validity of the signature on the properties (that’s why you need the IM cert) and you’ve got the user info.

It looks much better that the older systems when your server and the IM would have to talk to each other directly, which is not easy over the internet - AD is behind the firewall.

My use-case is simpler than yours because my users are only coming from inside of the corp network, so I don’t have to decide how to authenticate the users, but this is minor point.

I’ll let you know when I get an answer.

Hmm… doesn’t this mean that the widget is not protected? And that I can call that widget from any point in the world (or at least from any point within the corp network) and do whatever I want?

Not at all, it just means that instead of implementing SSO I built a fully embeddable widget.

You can call the widget from anywhere in the world, well of course, that’s the point of a widget.

When you say do whatever you want. What do you want to do more than what a widget exposes? Of course you can call the endpoints and what not, they are allowing CORS.

If you’re talking about simulating fake like and what not, just like Feature Upvote there’s throttling and filtering etc.

Not sure what you’re referring to. Happy to discuss how I implemented this if you have more questions. The goal of a widget, like Intercom’s for example is to be “public”.

Our users can wildcard domain that can embed the widget, of course.

Hope that answer the question.

Yeah, I may be missing something.

OK, suppose there is an internal corp portal. I’ve logged into it, and I’m on its page. The widget is loaded into a block on that page - from another server, I assume.

  • How does this widget (its backend server, more specifically) know who am I?
  • How does it authenticate that me is me?

Security folks told me that they do not use AD IdP (Identity Provider) for that, but Siteminder IdP. The protocol however is the same: SAML 2.0 Federated Services.

One correction they made to my idea of how it works is that IdP won’t accept authentication requests from just any application, because it creates a security risk: “Otherwise one application can get a SAML token and then send it to another web application.” As the result, the application has to be registered with IdP. Among other things, this step involves configuration what user attributes are sent from IdP to application (user FN, LN, id, whatnot).

1 Like

When the portal embed the widget they pass identification metric to the load function, exactly like Intercom receive current logged in user.

This is the responsibility of the “embedder”, they should embed only behind their own authentication mechanism.

So… if I embed the widget to a page on my own server within the corp network, I can pass any “identification metric” to it?

yes, why would someone do this kind of things, plus, the admin can whitlist certain domain where the widget can be embedded, so if you don’t want anyone to embed your widget, you specify which domain are allowed to embed

Unhappy employees do all kinds of stupid, malicious and backstabbing things. Experienced that first-hand.

Besides, the purpose of security is leave nothing to a good will of any actors; if a resource is secure, even if I want to harm it, I cannot.

This can help. However, in the context of corp networks, the hostnames and IPs are not as stable as the internet-facing ones.

The bottom line - if the client wants authentication against AD, this is their corp security standard, and to convince them to deviate from it is not an easy task.

On the other hand, a support for SAML Auth takes a SAML library in the HTTP filter (or whatever module can intercept the requests in your language of choice) and a bit of configuration. The application logic is not affected.

When you use an embeddable widget as a surrogate for SSO, the security usually works like this:

  • you give a widget url to your client.
  • you give a secret to your client for request signing
  • your client embeds this widget into their portal
  • your client embeds e.g. the user email in the request and signs this request with the secret
  • you verify the request and serve the widget

AD / SAML SSO should be done with a library i think. Doing this yourself would be much work (and requires much security knowledge / care of edge cases).

1 Like

Using the SAML protocol and Azure Active Directory as the “identity provider”, I’ve got a proof of concept of SSO working. I’m surprised by how straightforward it was. It is quite elegant too.

For now, I’m only going to offer Azure Active Directory integration.

I think the real challenge will be how to make it easy for my customers to set up and troubleshoot.

And edge cases, as mentioned by @unboot. I’m sure to run into edge cases. As per @unboot’s suggestion, I’m using SAML SSO libraries.


Usually the IT team of a customer will implement SSO, and they’ll have experience. These are usually not your app users, but the IT staff.

1 Like

While I agree that a widget can be secured, the steps that you list are essentially re-doing of SAML protocol, just poorly :slight_smile:

Yes, SAML Auth for Web is surprisingly simple, both to implement and troubleshoot.

If your SAML works for one IdP, it should work for any other too - provided that your application is registered to that IdP. In other words, that customer who wants the support for their AD IdP? They need to configure their IdP to accept your app requests, and on your side you just need to configure their URL - minimum work, as I see it.

Just in case, OAuth works only for authorization, for authentication of a user you need OpenID Connect, which is built on top of OAuth2 protocol. Some more on differences between them are here.