Single Sign-On (SSO) is an authentication method that allows users to log into multiple applications and websites using the same login data.
Lauritz Holtmann, Senior Consultant IT Security at usd HeroLab, has been dealing with the security aspects of Single Sign-On procedures both academically and in numerous customer projects. We asked for his assessment of account and data security:
“Single Sign-On is an elegant solution: practical for users and, at first glance, also a security gain: the increasing number of services we use every day, in private and professionally, also increases the number of passwords required. Instead of using many weak passwords that are easily remembered, this method offers the option of using one strong password for several services at once.
In a classic setup, a user must authenticate for each service with a user name and password chosen specifically for that application. In the Single Sign-On process, based on the frameworks OAuth 2.0 or OpenID Connect 1.0 for example, a third trusted party is included in the process: the so-called Identity Provider. This party is responsible for user management and communicates via standardized protocols with the so-called Service Provider on different channels for the purpose of authentication (“Who is the user?”) and/or authorization (“What is the user allowed to do?”). Identity Providers everyone is probably familiar with are Microsoft Azure, Google and Facebook.
But if you look a little deeper, the pitfalls are in the details. At protocol level, small errors in the configuration can already be exploited. This gives the Identity Provider a powerful position in the construct: For example, in large companies, if several central applications are indirectly linked to each other through Single Sign-On, a compromise can affect not just one, but potentially several applications.
This involves many different attack scenarios – to give two examples: The attacker could take over an entire end-user account on a service provider via the disclosure of OAuth parameters. In the case of the attacker controlling an application and if the identity provider does not correctly implement the withdrawal of tokens, the attacker may be able to gain unauthorized access to user data via the framework, even if the user has already removed the application from their account.
To reduce the risk of a successful attack on a Single Sign-On solution, we recommend already paying close attention to security aspects during the implementation of the framework and following recommendations made by security experts. However, since in some cases vulnerabilities can arise only in the interaction between the various parties and attack patterns are constantly evolving, regular security checks should be performed afterwards as well.
My colleagues and I have already tested numerous Single Sign-On solutions for security vulnerabilities and are happy to support you with a full implementation check. Our analysis goes beyond a pure configuration check. As part of a Greybox Pentest, we perform a technical analysis with multiple tests at protocol level. Only by this way we are able to show our customers concrete weak points and corresponding recommendations for measures.
Single sign-on, as I said earlier, is an elegant solution that will continue to grow in use, offering users convenience and a bit more security – but only if gateways besides from just credentials are reduced as best as possible.”
You want to have your single sign-on solution tested for vulnerabilities? Please contact us, we are happy to help.