Building Okta Mobile for iOS
Looks cool, right? Well, it was no easy task. A lot went into building Okta Mobile for iOS. I’d have to write a multi-page article to cover all of the aspects involved in building a mobile app, so let’s instead focus on the most interesting aspects of Okta Mobile. There are three key elements:
- Multi tab browser
- SSO wrapper
In addition to these key elements, I’ll also address memory management and the methods we used to get customer feedback during the development process.
The Okta Mobile app is essentially a multi-tab browser wrapped with Okta’s single sign-on (SSO) technology to simplify the login process for users. SSO and security are the core distinctions, but it is also equally important to develop an app browser that is as close as possible to a main grade browse. It was clear to us that SSO without the convenience of a multi-tab browser wouldn’t achieve successful adoption among our users. So, we set out to build a cool, performant multi-tab browser.
One of the most difficult parts of building a multi-tab browser is implementing a tab bar. There aren’t any standard iOS controls or popular open source browser tabs available to use ‘as is.’ UX is a priority at Okta, so we invested time and energy to implement our own tab bar.
Caching is another important consideration. NSURLCache with too much in-memory cache will result in frequent low memory warnings, while too little cache will result in a slower browsing experience for the user. The cache size must be balanced well for an optimal browsing experience.
Single Sign-On (SSO)
On the Web, Okta supports several SSO methods, including SAML and form-based authentication. These methods can be categorized in two ways: those that require a plugin execution on the client side (form authentication) and those that require server-based methods (SAML). We solved form-based authentication by developing Okta browser plugins, which reside in the client browser, to detect login pages and to complete SSO for the user. Okta provides different plugins for all major browsers (Chrome, Firefox, Safari and Internet Explorer).
Apple iOS does not provide plugin support in its Safari browser, ruling out a plugin-based approach for form-based authentication. We decided to build the Okta mobile app to handle SSO in mobile. How’d we do it?
Okta has already solved SSO for desktop browsers, so we used existing code to build mobile SSO. Okta Mobile leverages the existing SSO architecture to handle mobile SSO with minimal co-ordination code. For example, the mobile app does SSO for server-based authentication methods such as SAML by completely delegating it to the Okta server. The app simply makes a request to the server, which responds with a SAML-authenticated session. The Okta mobile app re-uses code written for browser plugins to handle SSO for form-based authentication.
The Okta Mobile app is built on top of the Okta API and, interestingly, is the first major client for our API. Every communication between the app and the Okta server is session authenticated. User identities are established through a login process and are re-established through a PIN challenge when users return to the app after a predefined timeout period.
By design, every SSO attempt in the app starts with a check to the Okta server, which validates session authenticity and then redirects the SSO request to the login web page. At the end of this redirection, the SSO engine in the mobile app takes over and completes sign on. It’s not possible for the app to handle SSO if the session is revoked on the server side because every SSO attempt is preceded by a check on the server side. This model is highly useful when a user’s device is lost, for example, because it’s only necessary to revoke the session on the server side. All subsequent SSO requests will be denied during the server check. A denial response from the server locks out the user from the app.
Have you ever wondered why mobile browsers refresh the page when you switch tabs? Or why there’s a limit on the number of tabs in your mobile browser? I too was frustrated until I realized why these non-user-friendly features are necessary in mobile browsers. The reason is quite simple. There isn't enough memory assigned to your app to keep DOM structures for so many tabs. The iOS environment gives low memory warning to the app when resources are tight, and the app must heed these warnings. If a recovery action isn’t taken, the OS will kill the app.
Engage With Customers Early
Making our customers happy is core to our company. We have great customers that are always willing to be involved in the development cycle, and they provide us with valuable feedback. Okta Mobile is no exception.
We used private, ad-hoc distribution channels to give our customers beta releases of Okta Mobile. We assigned a point of contact on Okta's side who collected valuable feedback from customers and channeled it back to the product and development teams. At Okta, development is an iterative process with our customers, which we repeated frequently before reaching the final version of Okta Mobile.