Configuring OAuth 2.0 token-based authentication

Connections Mobile supports OAuth 2.0 token-based authentication using the internet standard RFC 6749 – The OAuth 2.0 Authorization Framework. Because Connections Mobile is a public application available on public app stores, it implements the Authorization Code Grant Flow to an Authorization Server.

Overview

The following figure shows a high-level flow diagram showing how a mobile user logs in and then is able to access the Connections server.

flow diagram of user login
  1. The mobile user creates a Connections account. The app discovers that this server is using OAuth based authentication and launches a web view to handle the OAuth authorize request.
  2. The Authorization server authorizes the application, but it also authenticates the user. The authentication process used depends on how your Authorization server is setup, but it could use SAML or OIDC authentication flows to a central identity provider. Any mobile end user input that is required, such as using one-time passcodes, would occur inside the web form presented by the Connections Mobile app.
  3. Once a mobile user has been successfully authenticated, a short-lived authorization code is returned to the Connections Mobile app.
  4. The Connections mobile app closes the web view and uses the authorization code to request an access and refresh token from the Authorization server.
  5. The access token is used as the Authorization credentials for all Connections server API calls.
Advantages of using token-based authentication in Connections Mobile include:
  • Web based login forms Since the user authentication itself now occurs within a web view, the login form is free to use more complex forms that incorporate JavaScript of other active scripting. Depending on the capabilities of the authorization server and identity components, it may also be possible to provide customization to these forms that is now visible to mobile users. Both web and mobile users should now be able to share similar login experiences.
  • Extended login time for mobile apps Because the Mobile Server application uses multiple tokens for authentication, the expiration period can set to a relatively short time period for the access token, while setting the refresh token timeout to a much longer interval. The user is validated every time the short-lived access token expires, but the mobile user is only interrupted to revalidate using the web view when the longer-lived refresh token has expired.
  • User ID and password are never stored on the device When using OAuth, the Connections Mobile Server application is never aware of any mobile user credentials such as a login ID or password. Since it never sees them, it does not need to save these much more sensitive credentials locally. This improves the overall security posture of the Mobile Server application.