There was a time when the average computer user had to enter login credentials only once per day - likely to simply gain access into the Windows environment. But in this cloud-computing/mobile device age, unless you've activated the "stay signed in" option (assuming it's available), you'd probably have to login to 5 or even 20 different Web sites or online applications per day.
Many people already find it hard to remember a single username/password pair, let alone five or more. To work around this difficulty, some individuals use the same login credentials for all the sites or applications they need access to. But in doing so, they create a serious vulnerability. If a malicious individual gets hold of those credentials, he could potentially gain access to multiple applications.
That's why some organizations have started implementing SSO or Single Sign-On.
Note: Many of the applications we use these days are on the Web, so I'll be using the terms "web sites", "sites", and "applications" interchangeably throughout the article.
SSO in a nutshell
SSO is an advanced authentication, authorization and access control method that's built for environments where users normally access multiple applications everyday. Adopted by companies like Google, Facebook, Yahoo, PayPal, and Microsoft, who run online sites that serve millions of users worldwide, SSO is designed to simplify access to multiple applications and address insecure login practices.
Its most basic function is to enable users to login just once in order to gain entry into several applications. For example, after you login to Gmail (see screenshot above), you're automatically granted access to your accounts in Google-owned applications like Drive, YouTube, Google+, Maps, Blogger, Play, and others.
Ever seen this before?
You probably have if you frequent certain social networking sites like Pinterest, FourSquare, and StumbleUpon. This is another example of SSO. With it, you can use your Facebook login credentials to access sites that support Facebook logins.
While SSO is often associated with popular Web 2.0 sites, it's also actually ideal for and certainly applicable to various organizations.
Why organizations implement Single Sign On
SSO actually offers significant benefits. Here are some of them:
SSO reduces password fatigue
People are now subjected to so many passwords, that many of them eventually suffer from password fatigue. Password fatigue, which is caused by having to remember too many passwords, can force users to adopt insecure password habits - such as using the same password over and over again. But isn't using a single password what SSO is all about? Yes, but it's done in a more secure way. I'll explain this later.
SSO increases user productivity
When users have to login to multiple applications everyday, their productivity can suffer. Why? Because logging-in takes time. Logging-in to a single application would probably only take a second. But that only holds true if you only have to open one application and one application alone and hence have to remember only a single password.
But if you have to access multiple applications and hence have to keep multiple passwords, you'd have to open your list of passwords, scan through it, and type in the one that matches the application in front of you. That, I can assure you, takes time.
What if you forget or lose your list? That can be a big problem. You'll have to request a password reset and wait until you're issued a new password. What makes things worse is that lost passwords not only affect user productivity. They can also bring down the productivity of people tasked to resolve these types of issues.
SSO increases IT's productivity
Someone has to be in charge of generating, managing, and resetting passwords. That person or group of people would normally be your IT guy or IT department. Sometimes, your IT department would also have to manage other authentication credentials like digital certificates, tokens, and keys.
Managing security credentials for a large organization with thousands of users and numerous applications can be a headache. And yes, it can be a waste of time. Think of all IT's missed opportunities to innovate and engage in more productive endeavors just because they have to deal with password resets and other security credential management tasks.
SSO relieves IT of all these hassles because most of the tasks, especially password management, are now going to be handled by the SSO identity provider.
SSO encourages usage of Web-facing applications
Because of the considerable convenience it offers end users, SSO can potentially drive up usage of any service you provide through the Web.
Let's say, for example, you're providing users secure file transfer services and then you decide to adopt the same SSO used by Google Apps. So, once your users have already logged into Google Apps, they would then be automatically granted access into your secure file transfer service. They would be able to easily move from one application to the next (including yours) without having to log in each time.
This convenience can encourage them to use your service more.
Lastly, and perhaps surprisingly, SSO is actually secure. But before I elaborate on that, let me give you basic explanation on how SSO works. It will help you understand its security advantages compared to other methods.
A simplified explanation on how SSO works
Although there are different implementations of SSO, the general flow as well as the main players are almost the same.
There are typically three main players in SSO:
✔ Service provider - This is an entity (usually a server) providing a service (e.g. file transfers, video streaming, cloud-based word processing, etc.);
✔ User - A person who wants to use the service. The User connects with a Service Provider through a client application (e.g. an app running on a mobile device or a Web application running on a browser).
✔ Identity provider - A server where user identities and credentials are stored. This server is responsible for all user authentication tasks.
Here's a simplified version of a typical SSO flow:
1. User connects to the service provider;
2. Service Provider transmits an authentication request to the Identity Provider;
3. User is redirected to the Identity Provider for authentication;
4. User submits login credentials to the Identity Provider, who in turn authenticates the User
5. User is redirected back to the Service Provider, accompanied by a token confirming positive authentication and bearing User information and access rights;
6. User starts using the service.
Notice that the Service Provider doesn't, in any instance, perform user authentication. All of that is done at the Identity Provider. That's because all of the user's login credentials are stored in the Identity Provider. You'll see very shortly how this enhances security.
Is Single Sign On secure?
Let's now talk about what is perhaps the most common misconception about SSO. Many people think that, because SSO provides wholesale access into multiple applications, it provides a huge risk. Presumably, if a malicious individual acquires a user's SSO credentials, all applications protected by it can fall.
While that last sentence may be true, it's really an oversimplification of the whole story. We're usually tempted to jump straight to the part where a cybercrook already acquires SSO credentials, that we easily forget to analyze the chances of him succeeding.
Compared to current login practices, SSO logins can actually make login credentials less susceptible to unauthorized acquisitions. Let me explain by giving two common scenarios.
Scenario #1: A user uses the same login credentials for all online applications
In this non-SSO scenario, the user employs the same username and password for all sites he logs into. This is actually the worst case scenario. Many users aren't privy to the security of most of the sites they sign up for and yet they sign up anyway. Some of these sites may be secure, some may not (in which case, can be easily hacked). Some may even be rogue sites, built to steal confidential information - like usernames and passwords.
Both insecure sites and rogue sites can cause login credentials to easily fall into the wrong hands. Once those login credentials are stolen, all the lucky crook would have to do is find out which sites could be accessed with them. After that, hacking into the user's accounts in all those sites (including the secure ones) using the same username and password would then be a walk in the park.
Scenario #2: A user uses different login credentials
Theoretically, this can be the most secure method. Unfortunately, it can also be the most tedious and time consuming. One thing I'd like to point out is that - because many people don't realize this - even when a user employs different passwords for each application but also registers the same email address every time he signs up, he's still giving attackers an opening.
Once the email account gets hacked, it would be easy for the hacker to request password resets to all online applications linked to that email.
Why SSO can be more secure
When you implement SSO, all authentication processes and elements are handled by the identity provider. Many of these providers (e.g. Google, Yahoo!, AOL, Salesforce) are large and reputable organizations who have the means and motivation to establish really strong security. Thus, it would be extremely difficult for a cybercrook to acquire your login credentials from there.
SSO is better than Scenario #1 because even if the user attempts to connect to an insecure site or a rogue site, he won't be submitting his login credentials to them. Rather, he will actually be sending those credentials straight to the SSO identity provider. For as long as the user always makes sure he is logging into his identity provider, his login credentials will be safe.
You can learn more about SSO login best practices (particularly for the OpenID protocol), on this page.
Scenario #2 is theoretically good. In fact, probably the best, especially if 1) the email service provider is really secure, 2) the email account is protected with a strong password, and 3) the user maintains a secret list of passwords. Sounds good?
Not really. In every security endeavor, you need to consider the human factor. Let's face it. Not all users are going to maintain a secret list of passwords.
There will always be users who would want an easier way. If they find a security policy too inconvenient (like having to use different passwords), they'll circumvent it. It always happens. SSO is better because it relies on a highly secure system that makes policies relatively easier to adhere to.
SSO allows users to remember just one set of login credentials. All they have to do is keep those credentials secret. If they're able to do that, the security of the system will hold.
If you're looking for a secure file transfer server, we recommend one that supports SSO. Not only will Single Sign-On make it more convenient for your users to access your secure file transfer system (and encourage them to actually use it), it will also keep their login credentials safe. The latest version of JSCAPE MFT Server, which comes with a FREE fully-functional evaluation edition, already supports SSO.