Why Okta?
Who can forget Okta? It is basically a household name at many enterprise companies. Even if you don’t know about Okta, you probably recognize the name. Okta is a cloud-based identity and access management platform that provides secure user authentication and authorization services. It enables organizations to manage and control access to various software applications, systems, and data resources across multiple devices and networks.
In my opinion, the best reasons to use Okta are for multi-factor authentication (MFA) and single sign-on (SSO) functionality. It adds an additional layer of security, enables users to access multiple applications and services with a single set of credentials, eliminating the need for them to remember multiple usernames and passwords.
MFA is extremely important to secure the login flow because it adds an extra layer of verification beyond just a password, which are stolen and leaked every day through phishing and data breaches. We all love a security sidekick, but those extra authentication steps can feel exhaustive and over protective, especially if the login is happening on the same device with the same credentials.
This is where Remember Device comes in and allows users to conveniently access their accounts without the need for frequent MFA. Okta provides this functionality and has several recommended ways to implement it.
Getting Technical
Okta’s documentation provides implementation insight for the Remember Device feature. They have their own implementation, but it may be beneficial to generate your own token for the devices your users access the application from.
To achieve this, Okta exposes the “deviceToken” property that can be included in the context object of a standard authentication request. This device token serves as a unique identifier for the user’s device. Okta makes it clear that a property override is considered a highly privileged action, requiring an administrator API token. The introduction of the context object in this manner ensures Okta remembers this device token regardless of how the user proceeds through the authentication process.
This is where a problem starts to show up. Even if the user doesn’t explicitly set the “rememberDevice” query parameter as true during the MFA process, the device token will live in Okta for that user for some long unknown amount of time. Okta’s recommended approach saves the device token EVERY SINGLE TIME. Even if a user selects Do Not Remember, anyone who saves or has access to that device token can use it to bypass MFA the next time that account is logged in. This can be especially tricky when multiple users may have accounts on the same device.
In the Real World:
- 300 users login daily for 1 week
- 300 x 7 = 2100 device tokens stored in Okta per week
- Okta doesn’t provide any information on it’s threshold for storing these values
- All prior tokens are still active and can bypass MFA
Luckily, as with most technical challenges, the company responsible has already discovered a way to solve the problem. Let’s take a look at Okta’s own UI widget they provide for login and MFA.
Okta Uses Cookies
When authenticating through Okta’s widget, the same issue does not occur. If you take the device token generated on login, don’t select “remember device” and try to force that same token on a subsequent login, Okta treats it as a new device token. What is Okta’s widget doing that it’s documentation is hiding from us?
Okta uses the Device Token (DT) cookie as a secure token that is stored on a user’s device after successful authentication. It serves as a form of identification for the device and allows Okta to recognize and trust that device for future login attempts.
This cookie is used by their system to store during an MFA call if the rememberDevice query parameter is true. If that parameter is not true, then Okta will NOT save that token. When integrating with Okta through a custom backend service, if you really want to ensure that the device tokens you generate are not being maintained by Okta, then you will need to set the DT cookie value instead of the context object.
This is not a privileged action, it doesn’t save the device token. Okta even conveniently provides their own device token using that cookie if one is not passed in through the context object or the DT cookie on the initial authentication request.
What’s the Catch?
Unfortunately, this solution only works for Okta integration into a back-end service. Due to the updated Fetch spec, browsers block any JavaScript from accessing the “Set-Cookie” headers.
The only way to approach custom device token generation from a JavaScript front-end, is by using the context object and ensuring that each token generated is unique per user per device.
Conclusion
Okta still provides one of the strongest authentication systems in the tech industry and it will likely be around for a long time. If you want to have a more custom experience and generate your own tokens, keep in mind the issues that can arise from using Okta’s recommended approach. With a backend service, we can work around these issues and ensure we create only a single device token per user upon request. If your solution does not require customization, we recommend the Okta widget that already has the proper device token management built in.
This way Okta will only remember you the way you want them to.
For more information about Perficient’s Mobile Solutions expertise, subscribe to our blog or contact our Mobile Solutions team today!
