Spera is now part of Okta and its commitment to secure Identity. | Read more
As organizations increasingly adopt Software-as-a-Service (SaaS) applications, managing multiple usernames and passwords becomes a challenge. Okta, a popular Identity and Access Management (IAM) provider, offers Single Sign-On (SSO) solutions for these applications. One such solution is the Okta Secure Web Authentication (SWA), which allows users to sign in to SaaS applications using their Okta credentials, primarily for non-SSO apps. In this blog post, we will explore the concept of Okta SWA and its different configurations.
The concept of Okta SWA is simple. It is a browser plugin that enables SSO for web applications that don't support standard SSO protocols like SAML and OAuth. The app configured with SWA appears in the Okta dashboard, and users can click on it to launch the web application without entering any additional credentials.
Okta SWA supports two different configurations: Basic and Advanced. The Basic configuration allows users to log in to a web application by providing the username and password. The Advanced configuration is more complex and requires additional parameters, such as Multi-Factor Authentication (MFA) to provide a higher level of security.
The use cases for Okta SWA are diverse, but the most common scenario is when a company has a large number of SaaS applications that don't support standard SSO protocols or don't allow SSO in their basic licenses. In such cases, Okta SWA can be used to provide SSO, regardless of the SaaS application's limitations. Okta SWA can also be used to provide SSO to legacy applications that do not support any modern authentication methods.
Okta SWA allows users to set their own passwords for SaaS applications. However, this is not a recommended practice as it increases the risk of weak passwords and phishing attacks, and allows users to bypass Multi-Factor Authentication. Instead, it is recommended that admins set the passwords for the applications using Okta SWA.
Admin-set passwords are passwords that are set and managed by Okta administrators on behalf of their users for specific applications that are integrated with Okta. This feature provides an added layer of security and control for administrators, as they can ensure that users are accessing applications with strong, unique passwords that meet their organization's password policies. Admin-set passwords can also help mitigate the risks associated with password reuse and ensure that users are not using the same password across multiple applications. Overall, this feature helps strengthen the security of Okta SWA and the applications it manages.
Unfortunately, admin-set passwords are not always relevant or feasible. In the Github use-case, which requires an enterprise license to allow SSO connections, the account directory is globally managed by Github - and users work on their personal account. That means that the organizations do not manage their employees' users in Github and cannot configure admin-set passwords via Okta SWA to Github.
Some of Spera’s customers use the Okta SWA-Github integration, and we found that only 20% of their employees use the SWA plugin, while the rest login directly to Github without MFA enforcement and without sufficient password security.
Okta SWA is a useful security solution for SaaS applications that don't support standard SSO protocols. It allows users to log in to applications using their Okta credentials, simplifying the authentication process. However, user-set passwords in Okta SWA are not recommended. Instead, when possible, admins should set the passwords to ensure a higher level of security.
Spera is a critical complement to Okta and other SaaS applications, as it is used by organizations to help control the access sprawl, and secure their identities within these apps. Organizations that use Okta SWA will gain wider visibility through Spera - and cover their non-SSO apps as well as the SSO apps to create a single pane for Identity Security. Going beyond the obvious, Spera uniquely helps the security team monitor Okta SWA for any misconfigurations and acts when relevant, while protecting non-provisioned users with user-set passwords.
