TB.io mobile SDK
When developing a native mobile app, such as an iOS or Android app, you can choose between native login or Hosted Login. TrustBuilder supports both.
When using the native login flow, the user signs up or enters their credentials directly into the app. The credentials are then passed on to TrustBuilder by calling the TrustBuilder login APIs directly from within the app’s code.
When using Hosted Login, the user is redirected to the TrustBuilder login page in the system browser, where they can either sign up or log in. An iOS app opens a SafariViewController, and an Android app opens a Custom Chrome Tab.
TrustBuilder supports both.
Mobile SDK
To integrate your mobile app with TrustBuilder, you can build on any open source OIDC library of your choice (e.g. AppAuth for Android, iOS, and OS X). The authentication of step 3 itself is supported by the TrustBuilder Web Components. Configure the OIDC library to redirect to TrustBuilder and it will then take care of the OIDC protocol with TrustBuilder and ensure that the in-app browser returns the id token, access token and refresh token to your mobile app.
Note that security between the mobile app and TrustBuilder is achieved using PKCE (see RFC7636). The Proof Key for Code Exchange (PKCE, pronounced pixie) extension is a technique to mitigate the threat of man-in-the-middle attacks on the OAuth Authorization Code flow. It involves the client first creating a secret, and using that secret again after exchanging the Authorization Code for an access token. This way if the Authorization Code would be intercepted, it will not be useful since the token request relies on the initial secret.
Using Hosted Login
If your app-platform supports it, we recommend that you use Hosted Login (see Hosted Login) where your app presents an in-app browser tab (so-called embedded system browser) for login and signup. Using an in-app browser gives your app the benefits of Hosted Login, such as shared authentication state and security context, without disrupting the user experience by switching apps. An in-app browser login flow implementing the OAuth Authorization Code grant is illustrated below. The TrustBuilder Web Component hereby obtains an Authorization Code after successfully authenticating the user and passes that on to the app. The app then uses this Authorization Code to obtain the suite of tokens for further use of the TrustBuilder APIs.
Note also that since 2016, Apple and Google no longer allow “web-views”. With web-views your app would call any browser of the user's choice for login. Since this call leaves the safe environment of the smartphone, Apple and Google stated they only want to support the system browser invoked via "in-app browser tab". See for example Modernizing OAuth interactions in Native Apps for Better Usability and Security.
Pros & cons of Hosted Login on mobile
SSO across apps
If you have a suite of mobile apps, you might want to automatically log the user into all of them if they log into any one app. If your apps use the native login flow, your users have to enter their credentials for each app separately. With the browser-based login flow, you can implement Single Sign-on (SSO) reducing the number of times the user has to log in.
Google is currently working on a feature to synchronize sessions across devices, called Google SmartLock. This allows users to sign in using one device or desktop/laptop computer and automatically sync their session across all of their devices. To learn more, see Use passwords across your devices - Computer - Google Account Help. While SmartLock is not yet universal, using browser-based login flows allows you to take advantage of this tool.
Better security
As explained in the RFC 8252 OAuth 2.0 for embedded Apps, OAuth 2.0 authorization requests from embedded apps should only be made through external user-agents, primarily the user's browser. The specification details a number of security and usability reasons why this is the case.
With a native login flow, for example, a malicious party could decompile your app or or intercept traffic to/from your app and obtain its Client ID and the authentication URL. With this information a malicious party could create a rogue app, upload it to an app store as a game or so, and use it to phish for usernames, passwords, and access tokens.
Using a browser-based flow protects you from this, since the call-back URL is linked to the app through Universal Links (iOS) and App Links (Android). To learn more about Universal Links on iOS: see Universal Links - Apple Developer. To learn more about App Links on Android: see Enable Android App Links Support.
Reduced app store dependency
Using browser-based flows reduces the implementation time required, since everything is handled by the TrustBuilder’s login page, including multi-factor authentication and attack protection. Moreover, any change to the login page, including the addition of identity providers and authentication factors, does not require you to release another version of the app that needs to be approved by the app store.
Additionally, by relying on the TrustBuilder’s login page, you will automatically receive new features without requiring you to make any changes to your embedded app. For example, if TrustBuilder adds new authentication features, you would not need to make any code changes to your app before you can use this functionality.
Load time and user experience
When using a native login flow, the login UI and logic is included in the app. With a browser-based login flow, the user sees some loading time as the page loads. However, it's worth noting that the number of times a user logs in with the mobile devices is low. Once the user logs in, your app should only log them out if you revoke their access or if the user opts to log out.