Applications have come a long way in making your life better. Single sign-on (SSO) is one such thing that not only makes signing in or signing up easy but also secures the way you do it. But if you’re on the application building side, you need to make sure that the SSO functionality works as expected. And to get that confidence, you have to test it thoroughly.
So in this post, let’s discuss how to test SSO functionality and look at some important test cases. After that, I’ll tell you how you can make SSO testing simple and easy.
How to Test Single Sign-On (SSO)
There’s a lot that happens in the background when you click the SSO button and allow it to log on. When testing this functionality, you have to test for different scenarios:
- During the SSO process
- Post-authentication
- After logging out
Let’s start with the first category and understand what needs to be tested during the SSO process.
During the SSO Process
When you want to log on using SSO, there are two applications in the process. The first (further referred to as the “service application”) is the application that you want to log-in to, and the other (further referred to as the “authenticating application”) is the application that will authenticate you to sign-in. The service application requests the authenticating application to authenticate the user. You have to test a few things when data is being exchanged between applications.
Encryption
During this request, and when the authenticating application sends identity details to the service application, there’s a data exchange. The data should be protected securely. If it isn’t, hackers can use sniffing, MITM, and similar techniques to steal sensitive information. Hence, the best practice is to encrypt data and test encryption. You can use network interceptors such as Wireshark or Burp Suite while making requests and observe if the data transmission is secure.
Valid Data and Login
Service applications, along with requesting authentication, commonly request some details such as an email address, first and last name, date of birth, etc. But some service applications would need more information. These requests and responses happen through APIs. And because everything happens through programs, if invalid data is used, the program might crash, or the SSO might not be successful. Hence, it’s important to test the right data is being requested, and the valid data is being sent back.
Valid data retrieval is the first part; the next part is the effect of valid data. The goal is to sign on to the service application. SSO is just a smart way of doing it. So, while SSO makes things easier, focus on the goal shouldn’t be diverted. If the data is valid, then the application shouldn’t refuse to sign on. If the sign-on for valid data isn’t successful, then there’s no point in implementing SSO. You should test that SSO is using valid data in the service application. For example, if the email address retrieved during the SSO process is [email protected], the same should be in the service application.
The most straightforward way to test this is to use a set of valid and invalid account information and use SSO to sign in. The ideal behavior is that SSO should be successful for valid data and unsuccessful for invalid data. Any deviation from ideal behavior is of serious concern and should be fixed on high priority.
Server Performance
The SSO process requires applications to talk to each other and pass important information. This conversation should be to the point. You should check the server performance before and after implementing SSO. The purpose of SSO is to make sign-on easy and fast. But sometimes, if the code isn’t optimized, the process could have unnecessary delays. Testing this would help in identifying such issues and optimizing the code.
Post-Authentication
The SSO process, by definition, ends when the user is authenticated successfully. But it’s effect remains even after that. And because the authentication happens automatically, you have to test that the SSO process hasn’t broken anything post-authentication. Here are some cases in which you should test post-authentication.
Access and Privileges
Once a user is authenticated, they should access all the features and parts of the application that they’re supposed to. Access of users to various parts of the application and permissions to use features should be checked. You have to run checks to ensure that normal users aren’t permitted to make privileged actions, and privileged users aren’t denied privileged actions. Well, you could check this by manually signing on as different users and checking access. But this task is redundant and can be automated using smart, automated testing tools such as Testim.
Broken authentication is one of the most common security concerns. Even if the default access is correct, you should test that it can’t be manipulated. After sign-in, normal users are sent to the */home.php page and admin users to the */admin.php page by default. You should test if a normal user has access to the admin.php or similar features or pages by changing the URL. Though advanced broken authentication checks and security issues can be left for security teams to take care of, it’s good to run the most common checks.
Timeouts
SSO authentications usually have an expiry. Once a user is authenticated and logged in to the service application, their authentication would expire after some predefined time. They’ll have to log in again to get access. You should check if the timeouts work properly and if the user is being logged out after the expiry.
After Logging Out
Users’ access to the server application’s features should be disabled after they log out. They shouldn’t be able to execute actions that need them to be logged in. You can check this by logging out from the application and trying to access the application’s services. If you’re still able to do things on the application, you shouldn’t be able to; it’s a serious security concern. This case isn’t completely due to SSO. It’s most likely due to poor logout management coding practices. But there have been instances where poor logout management has occurred due to poor implementation of SSO. Hence, it’s important to test that.
Testing SSO Made Easy With Testim
After looking at some of the most common yet essential cases to test SSO, you might have noticed that most of the testing process is redundant. You have to do the same steps but with different values. This is time-consuming; it also gets boring, and you might miss out on something important. You can make SSO testing easy and more accurate by relying on smart and automated testing tools. I’m going to use one of the best tools out there and show you how you can do it.
The tool I’ve chosen is Testim. Testim is an automated software testing tool that uses AI for higher accuracy. It’s a complete suite that runs automated tests, records results, and allows you to create reports. It supports code and codeless testing. For now, let’s use Testim for a simple test. Let’s try to log in to GitLab using SSO and test if we can use a valid Google account.
Testim Example
Firstly, you need to log in to Testim. If you’re a new user, register on Testim. After you log in, click on the CREATE TEST button.
You’ll see the editor. Click on the first step or the record button and it will prompt you to enter the URL to test.
Then enter the application URL and click CREATE TEST.
Now, Testim will open a new browser window and visit the GitLab login page. Testim starts recording all your actions. On this page, sign in with a valid Google account. Once done, close the window. You can see all your actions in Testim’s Editor.
You can save this test for the future. If you click on the play button on top, the test will run again on its own.
The way you can use Testim for SSO testing is by recording the basic tests and running them after updates or releases and using different variables. To understand what else Testim can do, switch to the Testim usage Examples branch, and try various pre-stored tests.
Conclusion
SSO is a handy feature. But only when it’s working right. If you’re supposed to test SSO or any part of an application, for that matter, it’s better to do it in a time-efficient and accurate way. Irrespective of whether you know how to code or not, Testim can help you in testing. Now that you’ve seen an example of how Testim can help with SSO testing, check out more of its potential by exploring it yourself. Register on Testim.
