In our previous blog on Single Sign-on (SSO), we defined SSO and explained some of the many benefits it brings to the corporate table. To give a little recap: it saves time and money. That being said, we didn’t explain the nitty-gritty inner workings of SSO, the different types of SSO, and the distinctions users need to make when deciding on which form to go with. So let’s dive in.
SAML vs. OAuth
There are two primary open standards designed for SSO technology: SAML and OAuth. While SAML (Security Assertion Markup Language) came about in 2005 as a way to promote safe authentication across applications, OAuth (OpenAuthorization) was launched in 2012 as a response to the growing market of mobile devices and the need to access various resources and files with them.
SAML
Using SAML technology, SSO provides a secure form of authentication when accessing applications as a centralised identity source. With the same XML (Extensible Markup Language) standard for sharing data, SAML is implemented and shares security information about identity, system authorization, and authentication. Basically, SAML gives the infrastructure for SSO — and other federated identity systems — to be implemented on and protect login information. So, SAML offers a form of authentication; this is the major difference between SAML and OAuth.
OAuth
Surprisingly, OAuth doesn’t deal so much with authentication so much as it deals with authorization. Instead of creating a safe way to securely identify users like SAML, OAuth is a secure way to authorize user access to, let’s say, various online resources, accounts, and files. Instead of login credentials, OAuth allows owners of resources, web applications, and servers to authorize third-party access without having to divulge critical login credentials. In short, OAuth was designed for Hypertext Transfer Protocol (HTTP) to make online access safer for both the resource owner and the user trying to get access to it.
Based on the description alone, you can probably point to the types of organizations that use one over the other. SAML is used almost exclusively by large organizations that have a lot of employees needing safe access to a number of applications/servers. OAuth is typically used by companies that consistently have organizations and users requesting access to information for advertising and other purposes.
End-User vs. Organizational SSO
There are typically two approaches, or styles, to implementing an SSO system: end-user SSO and organizational SSO. Again, the needs of your business and where your resources are held will strongly influence which option you’ll choose.
End-User SSO
End-user SSO, as you may have guessed, focuses on how the end-user identity is processed and authenticated or authorized. When a company employs an SSO service from a provider like Okta or Salesforce, the interface is hooked up to all applications and servers that end-users will need access to. This is typically chosen by companies with very few applications and resources, and have few end users that are doing individual projects.
Organizational SSO
On the other hand, organizational SSO works better for bigger, more corporately directed companies that have a lot of end-users doing the same work (e.g., large manufacturers, software distributors, etc.). If your company has a lot of applications and a lot of end-users, then this will probably be a good option for you.
Moving Forward With SSO
Navigating through the various options for SSO implementation is a little tough, but if you know all the right functions and use cases you can easily pick an SSO style and provider. In our next blog, we’ll explore some of the other forms of secure login — for instance, Multi-Factor Authentication — and what makes them unique from SSO.
To learn more about SSO and how you can use it to your advantage, be sure to read our other blogs on the topic. And if you’d like a trusted partner to help structure your SSO solution, reach out to us here. We’re always here to help.