As one of the most commonly used and trusted forms of digital security authentication, SSO (Single Sign On) is an essential element of most applications that require users to sign in. SSO allows users to access multiple apps with a single set of credentials, which heavily boosts user experience and convenience without composing any security standard.
SSO is implemented using authentication protocols such as OAuth 2.0, SAML, or OpenID Connect.
Just like every application feature requires testing, so does the SSO implementation. This article will provide an in-depth exploration of this specialized area – SSO testing. It is intended to serve as a foundational introduction to the comprehensive field of SSO testing methodologies.
What is SSO testing?
SSO testing involves verifying the functionality, security, and performance of the SSO mechanism, ensuring users can access multiple services with a single set of credentials. The most common example is the SSO integration for Gmail in multiple applications; you can sign up and then sign in via your email credentials. No need for another ID and password.
SSO testing verifies that the single sign-on functionality works seamlessly across diverse devices, OSes, browsers and platforms.
Steps Involved in an SSO Test
- Functionality tests to ensure that the SSO integration functions as expected across all required applications.
- Security tests to ensure that SSO mechanisms handling private credentials guard the data from unauthorized access. Check for common threats like replay attacks and end-to-end data encryption.
- Performance tests to evaluate how the SSO function works under different conditions. Login time and system response rates are important metrics.
- Compatibility tests to ensure that the SSO functions well across different browsers, devices and OSes.
- Error handling tests to check system response to failed attempts, network glitches, server issues as well as the content of the error messages.
Additional Steps
- Defining test scenarios based on user roles, system interactions and authentication flows. Expect edge cases to cover all bases.
- Create dedicated test environments that simulate production conditions, incorporating all integrated applications, authentication protocols, and configuration settings.
How to test SSO authentication
SSO testing scenarios generally cover three phases:
- The actual SSO process
- The post authentication stage
- The post logout stage
The actual SSO process
To log in via SSO, you must validate two applications – a service application that you want to log in, and an authenticating application that enables the authentication required for signing in.
When a user tries to log in, the server app calls the authenticating app to verify user credentials. Test the data exchange between these two on certain metrics.
Encryption:
The data exchange between the two applications must be protected as it contains sensitive information. It should be guarded against sniffing, MITM and other methods hackers use to steal data. Test data encryption using network interception tools such as Wireshark or Burp Suite. Simulate various network scenarios and monitor for data leakage or the presence of unencrypted sensitive information
Valid Login Data:
In order to authenticate the user, the authentication engine will request relevant details – an email address, first and last name, date of birth, and the like. Data requests and responses occur through APIs. If invalid data is used, the program will crash or the sign-in won’t proceed.
Test if the right data is being requested, and if the program returns valid responses.
Once the data is retrieved, you must test if it has the right impact – signing the user into the service application. If the data is valid, the SSO should proceed. If the data is invalid, there’s no [point even testing the SSO because their datasets are the problem.
A common example is that the email address used during the SSO process should be the same as the email in the service application.
Simply create a set of valid and invalid data, and use them to test the SSO. If the sign-in goes through with the valid data and fails with the invalid, it works exactly as intended. Any other response is cause for concern.
Server status and operations:
Check server performance to ensure that the data exchanges between the service and auth application remain fast and concise. Does the server work as expected before and after the actual login? Is the process easy and fast?
Beware of any batches of un-optimized code that could lead to unnecessary delays and pauses.
The post-authentication Stage
When you test SSO mechanisms, don’t forget that the process doesn’t necessarily “end” with successful user authentication. Technically it does, but its effect continues post-authentication.
Since SSO occurs automatically, QAs must check that the process doesn’t change or break any core functions or UI elements after authentication.
Role-based access and capabilities:
Depending on the application, an authenticated user should have access to the right features after login.
Certain applications restrict access based on a user’s security clearance. Once they login via their credentials, the application should automatically allow them access to the right features and privileges. Normal users shouldn’t be able to utilize features or trigger actions meant for users with privileged access – and SSO tests must check for this.
Note: It is possible to run manual tests in which you sign in with different IDs and passwords. However, it’s easier if you automate such redundant tasks via automation tools like Testgrid (more on that later).
Write and run tests to detect broken authentication flows – something quite common in apps supporting SSO. Check if the default access can be manipulated.
After sign-in, regular users should be sent to the */home.php page. Admins, on the other hand, should be directed to the */admin.php page. Test if, in any scenario, a normal user is directed to the admin page and its privileges by changing the URL.
Timeouts:
SSO authentication sessions have expiration periods for security purposes. After the user has been authenticated and logs in, the authentication mechanism expires after a specific duration. Check if the session timeouts function correctly and expire as expected after the user is logged in. Improper timeouts are an inevitable security threat.
The post-logout stage
Once a user logs out, they should lose all access to the service application’s features, until they log back in again. They shouldn’t be able to run any actions or use any features.
Check this by logging out and trying to use the application features again. If it’s possible your app is carrying a massive security risk and will actively harm users.
Generally, bugs like this emerge from unsatisfactory logout management and coding practices or improper SSO implementation.
As a real world example, here’s a direct quote from Eric, who details his experience on the Adobe developer community forum.
“ SSO Testing. Here is what we did:
- When we recently changed the way we validate SSO (we use a Microsoft Azure application provided by WorkFront) we made the change on a weekend;
- When we made the change, I logged out and tried to log in using on-VPN SSO (“http://company.attask-ondemand.com/”>http://company.attask-ondemand.com/ ).
- I got an error. I was on Webex and everyone could see the Azure error in the lower right corner.
- Another change was made, I tried to log in again.
- Another error. More error message analysis. It took about 20 minutes of error message analysis and tweaking until I could log in;
- Once I could log in, I asked everyone on my team to try to login using on VPN SSO access, it worked for everyone; I tried to log in on VPN, not using SSO, Azure asked me to authenticate, it worked (“http://company.attask-ondemand.com/login)”>http://company.attask-ondemand.com/login) ;
- I dropped off the company VPN and tried to SSO in, Azure asked me to log in, it worked (correct behavior);
- I dropped off the company VPN and tried to login without SSO (“http://company.attask-ondemand.com/login”>http://company.attask-ondemand.com/login ). It worked.
- I tried to log in without VPN with a bogus ID, WorkFront wouldn’t let me in (correct behavior);
- Those were the four use cases. The two binary variables are: Login with SSO or not and Login with VPN or not.”
SSO authentication test cases
- Login Tests: Verify that users can log in with valid credentials and that they CANNOT login with invalid details. Both scenarios are essential test cases. In both cases, the system throws the relevant messages (success in the first scenario and error in the second).
- Timeout Tests: Does the SSO session expire after the right window of time? Do users have to re-authenticate to log back in?
- Password Changes: If a user changes their password, is the information updated across all linked applications? If not, the SSO mechanism fundamentally does not work.
- Role and Access Tests: Check that user logins match permissions and grant them access to features based on their privileges. Their credentials should map them to the specific features they need.
- Logout Tests: Verify that when users log out from one application, all other linked applications also terminate the session. Test session validity across platforms, including web, mobile, and other devices, and ensure local session data (e.g., cookies, tokens) are cleared upon logout.
- Cross Browser compatibility Tests: Verify that the SSO implementation works flawlessly and consistently across different web browsers.
- Parallel Session Test: Verify that the system allows (or doesn’t, as your project requirements dictate) multiple concurrent sessions on different devices with the same credentials.
- Data Recovery Tests: Verify that legitimate users can recover their account or reset their password, if they need to do so.
- Security Tests: Verify that the SSO protocol carries no obvious vulnerabilities for phishing, replay attacks and session hijacking.
- Network Connectivity Tests: Verify that the SSO system handles network disconnections and connectivity drops appropriately.
- User Experience Tests: Verify that the usage and speed of the SSO protocol is equally user-friendly across different platforms.
Why Testgrid can help you simplify SSO Testing
Given the many parameters that go into SSO testing, manually creating and executing multiple scenarios is impossible, especially in the modern world of “release a new feature every month”. You either automate your SSO tests (and most other tests) or you get overrun by a competitor who does.
TestGrid offers secure & scalable test infrastructure, hosting real mobile devices and browsers on cloud or on-premise. With TestGrid, users can also perform end-to-end test automation, including AI-powered codeless testing, mobile app testing, cross-browser, visual UI testing, and more. Test any app/website at scale, and ensure a flawless digital experience, every time.
Our customers have utilized Testgrid’s industry-best test infra to implement and expand test automation across different industries. A quick look at our success stories page will demonstrate that our cloud-based/on-premise test infra helps companies across completely different industries amp up and streamline test automation.
Testgrid also stands out withCoTester – the world’s first AI engine for software testing. The engine is pre-trained on advantages testing techniques, practices and standards as well as architectural standards and tools.
There’s more:
- Perform end-to-end test automation, including AI-powered codeless testing, mobile app, cross-browser, visual UI testing, and more.
- Execute local Appium and Selenium scripts on TestGrid’s scalable & secure test execution cloud.
- Test your website & web apps faster on a secure & scalable selenium grid powered by TestGrid. Run tests on real browsers & OS running on real devices.
- Cover every level of codeless testing, from record and playback, AI automation to low code/no code testing.
- Deploy your test infrastructure on premise and create a center of excellence for streamlining their testing process and saving costs.
- Host private dedicated devices on the TestGrid cloud and get 24×7 access for globally distributed teams.
- Host dedicated devices in a hybrid environment with; deploy devices both on-premise and on-cloud.
Simulate IoT testing by accurately replicating real component behavior and testing secure SSO authentication for IoT devices, removing time and access limitations for connected services and components. - Automate end to end API testing. Validate multiple data types, formats, and ranges.
If you’re intrigued but not yet convinced, why not try Testgrid for free? get 200 minutes of free manual testing on browsers and real devices, plus 30 minutes of Appium/Selenium test case execution on our cloud and much more.