1. Home >
2. Developer Blogs >
3. OIDC or SAML? Which should I choose?

---

OneLogin has robust toolkits, SDKs, universal connectors, and documentation to make it simple to connect your custom developed applications to our platform. OneLogin customers often connect their custom developed applications through SAML or OIDC. However, SAML and OIDC are the gold standards for a great user experience coupled with enterprise security. Both SAML & OIDC are well supported, and many customers have successfully integrated their custom applications with OneLogin through each standard. There are reasons why developers may settle on one standard vs the other. Below are decision points you can use to help you decide which SSO standard is right for your team.

Questions to ask yourself to see if SAML or OIDC is a better fit for you:

1. What languages/libraries are most common in our environment?
2. Are there custom mobile applications we need to consider?
3. What is the roadmap for our future custom applications?
4. What is the target audience of users that will be accessing our applications?

Let’s take a look at how answers to each question may impact your decision making:.

Question 1: What languages/libraries are most common in your environment?

Does your organization use a lot of TomCat servers or Java Servers for hosting applications? Are Websphere servers in place today? Many of the commonplace and longstanding container systems like TomCat or Java Servers come with easy to use SAML plugins that make supporting SAML easier for your custom applications. This is because SAML is a 20+ year old, well-adopted enterprise authentication standard. As a result, many legacy servers/containers have easy to implement plugins to meet this standard across different languages/libraries.

On the other hand, your team may be using more modern server/container frameworks like Node.js, AngularJS, or Vue.js. You may be building Single Page Web Applications (SPAs) for the majority of your new services. If that’s the case, a better authentication approach would be leveraging an authentication standard like OIDC that was built with JSON data structures in mind. If you see all future custom application deployments being built within these frameworks, it also may make sense to start leveraging OIDC now. Javascript developers will find OIDC much more intuitive to work with and libraries are continually being updated/improved to make OIDC deployments even simpler.

Question 2: Are there custom mobile applications that need to be considered?

If your team has or is considering building custom mobile applications, use OIDC rather than SAML. SAML as a standard was created before mobile application development became commonplace. As a result, few libraries/toolkits exist to integrate SAML with mobile workflows in mind. On the other hand, OIDC was developed as a standard with mobile use-cases in mind. Developers will find many more toolkits/guidance using OIDC for mobile application use-cases. Also, from a security perspective, the OIDC PCKE + Auth Code flow is considered the gold standard for mobile user authentication.

Question 3: What is the roadmap for our future custom applications?

What is the lifecycle of your current custom applications? Do you plan on building many more custom applications? Do you plan on migrating frameworks for your current application set? Are you mainly planning on maintaining your existing application set?

You might be sensing a pattern here but if you are planning on developing your custom applications on modern js frameworks (Node.js, Vue.js, or AngularJS) then OIDC is your best bet. If you have a number of custom java applications, PHP applications, and/or .NET applications that you plan on continuing to maintain into the future without significant framework/container changes, then SAML would likely be a simpler approach for SSO integration. That said, if the majority of applications you plan on developing are going to use js frameworks, it may make sense to plan on using OIDC for the new apps while leveraging SAML plugins for the legacy apps.

Question 4: What is the target audience of users that will be accessing our applications?

Do you plan on only having employees access these internal applications? Will multiple customers or partners need access to these applications?

While both SAML and OIDC can be used in tandem with OneLogin to provide access for multiple different types of users, SAML is a more developed standard for integrating with multiple IdPs. So, if you plan on providing access to your custom application directly through multiple IdPs, SAML is likely a better bet. That being said, OneLogin can be used (and many customers frequently use) OneLogin as a federation broker. This way you can connect many IdPs to OneLogin and have a single connection from your application to the OneLogin hub. In this model, your developers only need to worry about federating with one IdP (OneLogin). This means your developers can easily use SAML to give customers/partners access to your custom application without directly federating your application to each of your customers’/partners’ IdPs.

OIDC or SAML - what do I do?

In summary, you cannot go wrong with either SSO standard. Both standards will improve your user experience and offer better enterprise security from an access management perspective. OneLogin has out of the box SDKs, toolkits, libraries for both standards and you will find yourselves supported when connecting your custom applications to OneLogin regardless of the direction you take. You will find OIDC is generally seen as the future of enterprise web authentication with the rise of JSON, javascript, and SPA/mobile applications. If most of your development frameworks fit into this model, OIDC is likely the best fit. If you intend on integrating many existing PHP, .NET, and/or Java based applications with your IdP, then implementing SAML is likely the best path to take.

For reference:

1. OIDC Developer Guidance & Overview
2. Overview of SAML & OneLogin SAML toolkits
3. Sample OIDC Apps for Testing
4. Video of Using OIDC Inspector from OneLogin

---

---