Security at Okta – Covering Your Cloud
Okta is the market leading, on-demand identity and access management service that enables enterprises to accelerate the secure adoption of their web based applications, both in the cloud and behind a firewall. The functionality we provide for user authentication, password and access management, integration with on-premise user directories, and cross application usage analysis requires that the Okta service be both highly available and secure. To meet these requirements, Okta must provide exceptional security at all levels.
The Okta approach to ensuring security and reliability is comprehensive. It spans our hiring practices, the architecture and development of the software that powers Okta, and the data center strategies and operations that enables us to deliver a world-class service.
Secure and Reliable Platform
The Okta software platform is designed to provide both a secure and reliable foundation for a broad set of functionality that helps customers scale and manage their cloud applications securely. This includes ensuring all communications with Okta are secure and verified, that access to and control of the Okta service can be securely delegated across an organization, and that customer data is secure. Additional security measures prevent cross-site scripting, forgery requests and SQL injections. Okta works with external security experts regularly to validate the security of our design and implementation.
All access to Okta is over https. Customers are assigned their own domains, subdomains, and cookies. All requests are intercepted and validated.
Okta provides rigorous security measures and controls to protect our Production and Preview services. These controls are audited and attested to in our SOC 2 Type II report**. Additionally, Okta holds US-EU and US-Swiss Safe Harbor certifications.
Okta uses strong encryption to secure sensitive customer data. For example, we encrypt the unique customer SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. keys that are created to perform authentication on our customer's usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control.' behalf. We also store and encrypt credentials that users submit for downstream SWAAn acronym for Secure Web Authentication. SWA is a SSO system developed by Okta to provide single sign-on for apps that don't support proprietary federated sign-on methods or SAML. Users can enter their credentials for these apps on their homepage. These credentials are stored such that users can access their apps without entering their credentials each time. When users first sign-in to a SWA app from their homepage, they see a pop-up message asking if they were able to sign-in successfully. applications (apps), configured within their SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. environment.
Okta does not implement any proprietary encryption, and all customer data encryption is performed at the application layer.
The following illustrates the basic method, in which
- The passwords and keys for each customer orgAn abbreviation of organization, but can also be thought of as a company. A company that uses Okta as their SSO portal is generally referred to as an org. As an administrator, you decide how Okta should be displayed and/or integrated with your org. are encrypted using AES and a 256-bit, randomly generated symmetric key.
- This key-store, containing the customer symmetric encryption keys, is then encrypted with a Master Key that is held only in memory and only accessible to the Okta appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in..
- At startup, the app is provided a master passphrase allowing it to access, decrypt, and store the Master Key in memory.
A technical operations administrator inputs the master passphrase. Only eight administrators know this master passphrase.
Note: Since encryption and key management are occurring within the app, knowledge of the master passphrase does not preclude access to customer keys or customer data for the privileged administrators.
This process, using application level encryption, protects sensitive data, even in the event of partial compromise. As a result, attackers lack the ability to decrypt the data if armed with 2 out of 3 of the following: Master Key, Key Store, and/or the user's app context.
**This report can be made available under NDA. Contact Okta Support to initiate a request.
Secure Customer Data
Okta has taken several steps to secure customer data. For all queries, gets, and bulk updates, the Okta service returns or updates only validated data. Data is validated for each requestor in the context of the customer subdomain, https://<customername>.okta.com.
All Okta system responses to a request are subject to any access restrictions in place for that customer and their Okta registered users. This user/customer relationship is revalidated on every request to ensure that only authorized users within the customer’s subdomain view the data.
Secure and Reliable Operations
The Okta technical team has deep experience in developing and operating market leading on-demand services. Okta drew on that experience to conduct a comprehensive evaluation of infrastructure providers in order to select the right partner to complement our secure software development and enable us to accelerate the introduction of a highly secure and reliable service that easily scales as the needs of our customers grow.
Amazon Web Services is that partner. Amazon runs one of the world’s largest networks of web sites, serving millions of customers every month, and executing millions of transactions for their customers and sellers. Over time, they have developed significant expertise in building, operating, and maintaining the worldwide infrastructure required to power that business.
Together Okta and AWS have a comprehensive approach to ensure security and reliability of the Okta service. It starts with the physical datacenter, extends through the computer, network, and storage layers of the service, and is complimented by well-defined access policies and ongoing audit and certification by third parties including SAS 70 Type II Certification and SSAE 16 (SOC 2) Certification.
Secure Single Sign-On and Directory Integration
Many SaaS applications today support integration with single sign-on (SSO) solutions that adhere to the Security Assertion Markup Language (SAML) standard. Okta provides single sign-on capability and, for SAML compliant applications (service providers), Okta serves as a SAML Identity Provider (IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta.). The Okta service has the ability to respond to SAML requests from those applications with a SAML assertion response and facilitate secure user authentication.
Okta Secure Web Authentication
For SaaS applications that do not provide support for federated single sign-on Okta has developed Secure Web Authentication (SWA) technology.
Active Directory Integration
For many organizations, Active Directory (AD) is the core repository of users and the associated credentials that are used to govern access to network and application resources. Okta integrates with AD to extend this capability to cloud based applications and enables automated user import, provisioning, deprovisioning, and authentication against AD.
The AWS network provides protection against traditional network security issues including Distributed Denial Of Service attacks (DDoS), Man In the Middle (MITM) attacks, IP spoofing, port scanning, and packet sniffing by other tenants.
Okta uses a robust permissions model that allows very specific control while remaining extensible.
Security Vulnerability Protection
Core security features of the underlying Okta platform include the ability to prevent Cross-Site Scripting (XSS), Cross-Site Request Forgery (XSRF), and SQL Injection attacks. Strong validation of input and requests and strict programmatic controls on SQL statements minimize these threats.
Third-Party Penetration Testing
As part of our security strategy Okta hired a third party security testing firm, iSEC Partners, to perform penetration testing in an effort to understand and improve overall service security. The assessment included design review, source review and penetration testing. All testing was done using white box testing methodology, which entailed providing iSEC Partners with access to source code, binaries, technical documentation, and key developers. Okta developers worked hand in hand with the iSEC testing team to identify security threats and develop solutions to any potential threats.
Server and Physical Access
Each server in the Okta environment is monitored for machine health metrics twice per minute to track availability. AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All physical access by employees is logged and routinely audited.
Administrative access to the host operating systems to manage instances requires the use of multi-factor authentication. The administrative hosts systems are specifically designed, built, configured, and hardened to protect the management plane of the cloud. All access is logged and audited. Guest OS environments are locked down and completely controlled by Okta administrators. AWS has no access rights to the guest OS.
Secure Hiring Practices
Security starts with the people we employee. Background checks are performed on all candidates for Okta and employees, contractors and third party users must confirm in writing that they understand their roles and responsibilities regarding information security as part of their employment or vendor contract.