03 May What Is SSO and SAML and How Can They Help You Manage Authentication?

Working with user credentials is a sensitive and difficult application process that many developers struggle to do securely. If you can’t think like a hacker and understand the many ways an attacker can gain access to user credentials, then even the best application might be vulnerable to exploits, which can lead to expensive data breaches.

Regulatory guidelines such as HIPAA and PCI-DSS attempt to direct developers with standards that protect data, but mistakes can still be made. With Security Assertion Markup Language (SAML), user credentials are managed by a trusted entity (Google or Facebook, for example) and users can authenticate into a system without the need for a developer to security process and store username and passwords.

A Brief Overview of SSO and SAML

If you’ve ever logged into a site that displays buttons such as “Log in with Google” or “Log in with Facebook,” you’ve used single sign-on (SSO) functions. SSO lets software developers use third-party applications to authenticate and authorize user accounts. The software developer doesn’t need to ensure security of usernames and password, no user information is stored (unless it’s provided by the third-party) and users don’t need to take time to enter their private information into another website. Convenience and security are two main advantages of SAML and SSO authentication.

 SAML and SSO have three basic requirements:

• A principal – the end user authenticating into the site using their account at a third party.

• An identity provider – the third-party entity that stores the user’s credentials (Google or Facebook, for example).

• The service provider – the application developer using SSO functions to authenticate the user.

When a user signs on using a third-party entity, permission is given to the identity provider to pass information to the service provider. If multiple layers of private data are stored at the identity provider, the user is informed of the data that the service provider wants to access.

For instance, when you use Google to sign in, the service provider might want access to account information and Google Drive. Users are informed of the information they are divulging to the service provider and asked to confirm that they give permission to the service provider to access the data. After confirmation is given, the service provider receives data and a token.

The principal can revoke the token at any time, which means the service provider can no longer access the user account data. The token should be protected from third-party view because it’s the authorization identity that can be used to access the user account data from a remote application.

Authentication and Authorization

Authentication and authorization are two different concepts that make up cyber security access. Before developing applications that use SSO, it’s important to understand the difference between the two so that you know what happens after you receive a token from the identity provider. 

Just because the user authenticates into a system does not mean you have authorization to access account data. Authentication is the process of ensuring the user is who he says he is. Username and password credentials are the typical way to verify a user, but biometrics and two-factor authentication are two other ways. With SSO, two-factor can be incorporated into authentication, but biometrics validation is complex and expensive, so it’s not a standard security method online.

Authorization is the process of providing access to the layers of account data after authentication. The developer might just want the user’s name and email account. Other developers might need access to components from the identity provider. For instance, an application that works with Google Drive requires authorization to access this component of the user’s account. 

When working with SSO, the SAML response provides attributes and properties of the user account and the authorization provided by the user. If authorization isn’t given, the developer can send a message to the user or block access.

Advantages of Using SSO and SAML

Using SSO identity providers, none of the private, sensitive information users need to authenticate are stored by the service provider. Service providers no longer need complex encryption mechanisms and cyber security needed to protect authentication sections of an application.

Should an attacker be able to bypass security in the application, no credentials would be disclosed. Since cyber security attacks are so common, SSO is especially useful to developers that do not have the experience or resources to secure against common cyber security attacks. 

For users (principals), a larger trust factor is given to big tech giants such as Google and Facebook knowing that these corporations pour millions into penetration testing and protecting user identities. Information is only disclosed if the user gives permission to the service provider, so the developer can convince more users to sign up especially those hesitant to give their private data to an unknown application developer.

Another advantage is that developers no longer need to create their own authentication and authorization procedures. These components of an application can be complex and need extensive testing to ensure that they work correctly for end users, but also have the right security coded into them to avoid data breaches. It’s one less hurdle for the developer to overcome when coding a new application, which also saves on development time.

SSO and SAML are incorporated into several online applications, so the technology has tested, tried and proven to be a great solution for developers that do not have the time or resources to implement a custom authentication and authorization system.  The advantages for developers and users are numerous including security, a reduction in development time, and fewer resources needed to store data.