OneLogin handles passwords, encryption keys, and certificates securely in order to provide a seamless and safe authentication process. Whether authenticating users to the OneLogin portal or authenticating them to applications, OneLogin only stores portal passwords and passwords for applications that do not support token-based SAML authentication. Stored passwords are always securely hashed or encrypted.

This FAQ provides answers to common questions about how passwords, keys, and certificates are used and secured.

What passwords do you store and how do you store them?

OneLogin only stores portal passwords and passwords for apps that do not support token-based integration. We do not store user passwords for federated user accounts. Passwords are always securely hashed or encrypted.

OneLogin performs the following types of authentication:

• Authentication into the OneLogin Portal
• SAML authentication
• Form-based authentication

For authentication into the OneLogin Portal, OneLogin establishes a secure network connection (TLS using a digital certificate with 2048 bit RSA key) over which the end user’s password is transmitted. The password is validated against a trusted user store like Active Directory, or OneLogin itself. If the user store is OneLogin, OneLogin hashes the password using the bcrypt algorithm and compares the stored salted hash against this hash to validate that password.

In SAML authentication, an application is configured to use an identity provider such as OneLogin as its only source of trusted authentication for the account. In this case, there is no application password used at all. When a user signs into a SAML-configured application, the application authenticates the user based on a secure token from the identity provider, such that no credentials are ever used in the login process. OneLogin has 600+ SAML-enabled applications in its app catalog. Many popular apps such as Office 365, G Suite (Google Apps), Salesforce, Concur, AWS and Box use SAML.

In form-based authentication, a web application presents a username and password web form for a user to fill in. In these cases, OneLogin needs to push the username and password values into the browser using the browser extension in order to authenticate the user. Because of this, OneLogin cannot store passwords as a hash; if it did, there would be no way to decode the password to push it into the browser. Instead, OneLogin stores passwords encrypted using AES-256 in a Password Vault.

How do you manage your certificates and encryption keys?

Certificates and their matching public keys are public information and do not require special protection.  Access to keys is restricted to a small number of OneLogin employees.

OneLogin uses the following methods to generate and secure certificates and keys:

• SAML certificates: Certificates are generated by the application using a pseudorandom generator with a long expiration period. Customers have the ability to manually generate new key pairs and update cloud applications within the OneLogin app as needed. Access to these certs is restricted to customer account administrators and OneLogin Customer Support, upon request, when providing support.
• Website HTTPS (SSL/TLS) certificates: Certificates are issued by a trusted third-party Certificate Authority and are managed and reviewed by OneLogin administrators. Certificates are stored in an encrypted database and are deployed to host systems automatically. Access to these certificates’ deployment (certificate+private key) is restricted to the OneLogin operations team that supports our production environment.
• Device and user certificates: Certificates are generated by OneLogin’s own Public Key Infrastructure. Our PKI deployment is lean and secure: one Root CA that is completely offline and two Intermediate CAs (for redundancy). These Intermediate CAs also serve as Registration Authorities and Verification Authorities and are behind a firewall, accessed only through an application proxy. OneLogin does not store private keys for users or devices and only stores private keys for its own service certificates used for authenticating devices and issuing additional certificates. Access to the certificate deployment (certificate+private key) on the CAs and to the servers is restricted to the OneLogin operations team that supports our production environment and access is monitored in real time.
• Password keys: We protect application passwords using a set of symmetric keys that both encrypt and decrypt and need to be carefully protected. The app automatically generates one key per account during setup. This key is used for encryption of passwords, and the key itself is encrypted using OneLogin's master key. These keys are stored in separate locations and access to these keys is restricted to the OneLogin operations team that supports our production environment. However, the keys are only used by the application itself, and access to the master key is monitored in real time.
• Backup protection: We protect our backups in transit with TLS and at rest using server-side encryption with Amazon S3-managed encryption keys (SSE-S3). Access to the stored backup files are monitored in real time.

What authentication factors do you support and how?

OneLogin uses passwords as the primary authentication factor, and complements passwords with a variety of multifactor authentication (MFA) options. OneLogin also offers security questions and browser certificates as secondary authentication factors, as well as fingerprint biometrics for OneLogin Mobile.

OneLogin allows you to use a combination of the following factors for authentication:

• Passwords: Required for authenticating into OneLogin. Passwords cannot be blank, and OneLogin administrators can manage complexity rules for their organization. 
• Multifactor authentication (MFA) methods like RSA SecureID, Google Authenticator, and Yubico, to name a few. Software MFA solutions, like OneLogin OTP mobile app, generate a one-time password (OTP) that displays on a user's mobile device, and which users enter into (or push to) the OneLogin login page. Hardware MFA providers use specialized devices (like "key fobs") that generate OTPs, or require that the device be connected directly to the user's computer to inject the OTP into the OneLogin login page automatically. A third type of MFA solution sends the OTP to a mobile device via SMS. OneLogin supports all of the most commonly used MFA providers.
• User browser certificates: PKI Certificates prevent access to OneLogin accounts from unauthorized browsers. These can be downloaded and installed on the local machine by the authorized end user.
• Security questions: Depending on how many questions admins require, end users can choose the questions they want to answer for account authentication, unlocking accounts, and resetting passwords.
• Fingerprint: OneLogin supports the use of biometrics, such as Apple TouchID, for its mobile launcher application. Instead of entering a PIN to access applications through OneLogin on a mobile device, the user can leverage the fingerprint they have registered with TouchID in their smartphone to authenticate into their account. Note: if your organization requires users to use biometric authentication to access the OneLogin mobile app, users whose devices have no biometric function will be unable access their OneLogin portal on their device. 

Figure 1. One-time password (OTP) authentication

How does OneLogin’s Password Vault work?

OneLogin stores passwords for apps that use form-based authentication in a proprietary system called the Password Vault. Vaulted passwords are stored using redundant levels of encryption for security robustness.

Each customer account in OneLogin has an account key that is used to encrypt all user passwords in that account. Each account key is then encrypted by a master key that is securely stored separately from the account key. All of this is done on the OneLogin server side, and all passwords are encrypted with AES-256, a strong symmetric encryption algorithm.

Figure 2. OneLogin's Password Vault

What happens to passwords for apps that use APIs for SSO?

A small number of applications that don’t support SAML provide the password to the application using the application’s API. In such cases, the password is stored encrypted and sent over an encrypted channel (SSL/TLS).

Some applications, such as Hipchat, allow single sign-on through their API so that users can access the app as if it were SAML-enabled, for example through desktop and mobile applications. Other applications, like G Suite (Google Apps) support SAML but optionally use an API to provision the OneLogin password as the app password. In the case of G Suite, this allows email clients, like Microsoft Outlook or iOS Mail, to access GMail.

What is the OneLogin browser extension and what does it do?

By securely storing and retrieving user credentials from OneLogin’s Password Vault, the browser extension automates the login process for apps that use form-based authentication, including those that only support basic authentication.

OneLogin browser extension leverages user credentials stored in the OneLogin cloud-based Password Vault. The credentials are fetched by the browser extension only when the user is signed in to OneLogin and launches a form-based application to which she has access per corporate policy. OneLogin decrypts the password and generates a snippet of JavaScript that injects the credentials into the page and signs the user in.

Figure 3. OneLogin browser extension workflow

What happens to passwords during Windows Domain Authentication?

OneLogin's Desktop SSO uses Integrated Windows Authentication (IWA) to sign users into OneLogin automatically once they have signed into their Active Directory domain. OneLogin never sees the passwords used in Desktop SSO.

OneLogin users are authenticated against Active Directory (AD) when they log into their desktop on-premise. When a user attempts to launch a OneLogin-managed app on-premise, she is redirected to an on-premise authentication service that verifies her identity against the AD domain before issuing her a token to OneLogin and providing her access to the app.

Figure 4. Desktop SSO

How do users reset their OneLogin portal passwords?

OneLogin offers a number of ways for users and administrators to reset portal passwords.

Administrators can manually reset end-user passwords through the admin portal. Admins can also give users access to self-service password resets through security policies that can be applied at the user level. Admins can also choose to allow password resets via email, by answering multiple security questions, or by entering an SMS code sent to a user’s registered device. If an external directory is connected, password updates are synced.

Any password changes are logged as a OneLogin event that can be viewed in the OneLogin admin portal or streamed to a Security Information and Event Management (SIEM) system, such as Splunk, ELK, or Sumo Logic.

Figure 5. Self-service password reset flow

What is the purpose of the Assume User feature?

The Assume User feature is intended strictly for diagnosing and troubleshooting account issues. Account admins can enable and disable the feature as needed.

The Assume User feature allows account administrators to assume users in order to diagnose and troubleshoot minor issues, and it allows OneLogin support staff to assume accounts in order to help administrators solve major issues. This feature can be disabled at the account level and at the app level.

Admins who are assuming an end user can launch a user's application only if the app has been enabled for an assumed user to do so. Admins who are assuming a user cannot see that user’s app passwords or secure notes. Whenever an admin assumes a user, it is logged as a OneLogin event that can be streamed to a SIEM.

What does all of the above mean for my application sourcing strategy?

When possible, choose applications that use SAML authentication over applications that use form-based authentication.

SAML-based authentication eliminates passwords, using secure tokens to assert identities, and thus is more secure. SAML authentication ensures that only valid, enabled users are able to sign in to an application and can quickly be provisioned and de-provisioned by admins.

Here is a list of some of the software applications that support SAML for authentication: App Integration.