Authentication is one of the biggest problems facing anyone building apps integrated with cloud services.
You don't have to search much to find stories of developers hard-coding authentication tokens into mobile apps and accidentally leaking valuable keys or account details into the wild. With more and more apps being built by nonprogrammers to work with multiple cloud services, that risk can only grow. Controlled user authentication needs to be part of any modern application development strategy.
Building your own authentication and authorization tooling isn't easy. Does the service you're working with use OAuth, SAML, or something custom? If it's OAuth, which version? Then there's the question of federated identity: Do users need a separate ID for each service, or should they have a single sign-on tied to their corporate identity? Finally, there's the problem of bringing new users onboard and of deprovisioning those who no longer need access to an app -- or who have left the company.
It's a problem we've tried to solve again and again, building webs of trust that struggle to bring our apps and services together. So how do we make new apps safer without increasing the risk users will reject them for being too complex? The answer, unsurprisingly, comes from that new world of APIs and cloud services, with a range of different platforms that offer single sign-on as a service and controlled access to cloud services as well as internal APIs.
Microsoft's cloud-hosted Azure Active Directory goes some of the way to solving this problem, with its built-in single-sign on tools and support for user roles and groups. Users can log in with their familiar Windows user ID and password, and are then issued authentication tokens for registered websites and services. An open source framework, Katana, can be used to build this into your apps and services, with tools for working with ASP.Net Web apps and for native applications.
Building on the ADFS (Active Directory File Service), it's a useful platform for controlling user access to services like Salesforce or Office 365 (with support for contextual security reports that can help track down compromised accounts). While you can use it in your apps, it's still not the easiest tool to use, requiring native .Net code to access all its features.
An alternative approach comes from single-sign-on service Okta, which now offers REST access to its features so you can build them into applications using your choice of development tools and platforms. Apps can work with Okta's cloud store, letting users access Okta's log-in service from inside an app.
Okta is best thought of as a managed credential store for your apps. While it handles log-in for sites and services (much like Azure AD), you can use its REST APIs to log in users and then request the appropriate credentials for the services you're calling from your app. Credentials can be set by the user or provisioned by IT departments as part of bringing a user on board or changed when a user changes roles.
Wrapping identity services in this way enables automated password creation, so ridiculously strong passwords can be generated without users having to memorize them. Plus, the audit tools and contextual security features built into a modern identity platform make it much more likely that compromised passwords can be identified and locked out. Role-based identity management means that users get access only to the services they need. Accounts can be de-provisioned easily when users leave the company.
Cloud identity services like Azure AD and Okta are able to use their relationships with SaaS providers to support changes in authentication methods quickly, seamlessly handling switches from OAuth to SAML, proprietary to open. They also enable admins to add additional security, such as various forms of two-factor and push authentication. In fact, Okta's latest push tools will have an authentication token waiting for you on your phone as you open the log-in page for a supported site.
Having one place to control usernames and passwords isn't a perfect solution to the problem, but until we get an open standard for federated claims-based identity and some form of easy credential look-up, it's probably the best we can do. Using tools like Okta, a user only has to log in once, and your app can then take user credentials from the Okta service in the cloud and use them against a service's own authentication service.
Instead of having to build complex sequences of log-in screens into an app, and possibly storing tokens and credentials in insecure and untrusted mobile devices, we now only need one log-in screen, and only one set of credentials. You'll still need to manage authentication and authorization with the services you're using, though most service SDKs provide simple mechanisms for handling this.
When you build apps around a service like Okta, there's no need for a user to know what services an app uses. Users just log in and everything is handled behind the scenes. The result is a simpler world for users, developers, and IT admins.