Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Add Authentication o Your iOS Apps With Centralized Login, Part 1

DZone's Guide to

Add Authentication o Your iOS Apps With Centralized Login, Part 1

In this series of posts, we will take a look at the recommended approach to performing authentication in native iOS apps. Part 1 will serve as an intro to the subject.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

In this post, we will take a look at the recommended approach to performing authentication in native iOS apps. We will use Auth0's Centralized Login feature to increase security and follow OAuth2 and its recommended practices on iOS. We will also learn how to use the new SFAuthenticationSession class from iOS 11. Read on!

Introduction

When a user needs to be authenticated in a mobile app there are essentially two options: an internal (embedded) login screen, or an external login screen.

Embedded login screens have been the norm for a long time. Starting with the usual username/password login screen from Facebook, to modern ones that allow you to login by using a cell phone number and SMS or emails. The are two issues with this approach:

  • Login credentials are seen and managed (and even stored in some cases) by the application. This means that any security issue affecting a single application can compromise those credentials.
  • Implementing single sign-on solutions is impractical due to the necessary isolation requirements of mobile operating systems.

The main advantage of embedded login screens is the seamless integration with the rest of the application. There is no screen-switching or extra delays related to switching applications to perform logins.

External login screens, on the other hand, work by delegating the job of authenticating a user to a different application. The main advantages of this approach are:

  • A specialized, secure, and OS sanctioned (i.e. with special privileges and behavior) can take care of the sensitive part of the authentication flow: handling credentials.
  • Multiple applications can delegate authentication to the same external application, allowing single-sign-on solutions to be implemented with ease.

The main disadvantage is, of course, that delegating authentication to a separate app is not as seamless as an embedded login flow.

When it comes to iOS, the external app that handles authentication is usually Safari. By having Safari access an authentication server, login credentials are managed by it. Apple, and other OS manufacturers, pay special attention to the way web browsers handle this information, and development is focused on making this secure. By making the web browser the external app that handles authentication and credentials, security for all native applications is increased.

But can we do anything to improve the user experience when using external logins? At Auth0, we developed Centralized Logins to give our users the best of both worlds. Centralized Logins allow developers to customize the login screen that is served by Auth0 when used as an authentication server. Of course, in case developers don't want to customize the login screen, they can use the default Auth0 Lock screen that supports a lot of functionality with minimal coding. In other words, it can even result in less time spent developing this feature for your app!

Before taking a look at how to use this for our iOS apps, we will take a brief look at how this works in the context of OAuth2. OAuth2 is one of the industry-standard technologies implemented by Auth0.

OAuth2 for Native Mobile Apps

OAuth2 is an authorization framework. In practice, OAuth2 can be seen as a protocol for clients to gain access to protected resources managed by different parties.

On the other hand, authentication is the process of confirming the truth of a user's credentials. In simpler terms, letting an application know the identity of the user interacting with it and validating that identity.

Authorization is more general than authentication, thus OAuth2, an authorization framework, can also be used for authentication purposes. However, since OAuth2 is designed with a bigger scope in mind, to use it for authentication it is necessary to specify with greater detail certain operations. This is what OpenID Connect, a protocol built on top of OAuth2, does for authentication.

When it comes to mobile apps, many applications require the user to identify themselves, or to authenticate. Nowadays, it is very common to delegate that functionality to third-party identity providers such as Facebook, Twitter, or Google. This is known as social login in some circles, but it can be used with any identity provider supported by the authentication system. Each identity provider provides their own authentication and account access process. Some of them, like Google, rely on OAuth2. Others may choose different protocols.

Mobile apps have been, for a long time, designing their own authentication and authorization screens. All of these screens must conform to the authentication and authorization process of the identity provider. For example, if Facebook requires a user to authorize a third party application to learn their full name, e-mail address, and profile picture, a consent screen must be displayed. This process is entirely controlled by the identity provider.

For web applications, this process has always been handled by the web browser. Web browsers allow identity providers and services to communicate with each other, while at the same time temporarily controlling each step of the authentication/authorization process. Mobile apps, by virtue of preferring native login screens, have strayed from this path. It is for this reason that the IETF has drafted a document detailing the advantages of also having mobile apps use the web-browser for authorization.

In essence, a native application can delegate the authentication/authorization steps to an authorization server through the web browser. Web browsers on all mobile platforms provide ways for the results of these operations to be sent back to the application that requested them. Furthermore, web browsers are fully prepared by the OS vendor to handle these operations securely.

Auth0, which fully conforms to the OpenID Connect specification, provides an authorization server capable of authenticating and authorizing users through many identity providers using mobile web browsers. The next sections in this series will detail how to implement this for iOS apps, both hitting OpenID Connect endpoints manually and using the Auth0 SDK. Additionally, we will also see how to customize the different screens that are displayed by the web browser during the process, improving the UI/UX integration with the rest of the applications.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,mobile application security ,ios security ,web application security ,authentication

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}