Skip to content

Overview

Authentication

Using the optional Authentication module, Launcher provides single sign-on (SSO) to devices by authenticating users through the customer’s identity provider (IdP). SSO allows other applications to verify that authentication via the Launcher.

Launcher can be configured to require the Auth module to revalidate with a secondary form of authentication (PIN, biometric, barcode, or NFC tag) each time the screen is awakened while Launcher is logged-in. For more information, see the documentation on Secondary Authentication.

Supported Identity Providers

  • OpenID Connect (OIDC) compliant IdPs (including, but not limited to):
    • OKTA
    • Azure Active Directory (AD)
    • OneLogin
    • ADFS 2012, 2016
    • Keycloak
    • Ping
    • CyberArk
  • Secure LDAP (LDAPS)
  • REST API-based IdPs
  • Custom integration with in-house Authentication databases/systems

Authentication Architecture

For OpenID or OAuth2 IdPs, the Authentication module authenticates with the IdP via a webpage using Chrome Custom Tabs (CCT).

Once authenticated, the Auth module will perform the code/token exchange to retrieve the access and refresh token, and pulls the user information from the access token claims.

Because of the shared cookie store using CCT, modern apps that authenticate with Chrome will be automatically authenticated, facilitating SSO.

This exchanged tokens and user information is temporarily stored in a shared token store, accessible via BlueFletch Enterprise SDK, until the user logs off or the device is rebooted.

Apps using the SDK do not need to build their own authentication mechanism, but they are required to have authorization logic based on the presence of a Launcher session/token.

Authorization Components

Beginning in Auth 4.x, the authentication webpage for an OpenID or OAuth2 IdP can be configured to open in either Chrome Custom Tabs (default) or the BlueFletch Browser. The authenticating browser is defined by the browser value.

Authentication Broker for Legacy Apps

Optionally, for legacy applications that use a Webview, after the user is successfully authenticated, the Auth module starts an HTTP server that acts as an Authentication broker that runs within the device.

The legacy app can be pointed to this Auth broker, and the Launcher will share its tokens with the app by responding to the legacy app’s authorize and token requests.

The Launcher can share its existing tokens, or authenticate on behalf of the legacy app, providing unique tokens per app.

Authorization Components

Application Details

Package: com.bluefletch.ems.auth

Auth 3.x

To find the latest application binary versions, see the BlueFletch Portal Downloads page.

IdP Application Name
LDAP Auth - LDAP
OKTA Auth - OKTA
Azure AD Auth - MSAL
ADFS Auth - ADAL
OKTA (REST) Auth - OKTA Session

Auth 4.x

To find the latest application binary versions, see the BlueFletch Portal Downloads page.

Protocol IdP Application Name Minimum Version
OIDC-compliant OKTA
OneLogin
CyberArk
Ping
Keycloak
Auth - OIDC 4.2.x
OIDC (Azure-specific) Azure AD Auth - OIDC-Azure 4.3.x
LDAPS Any LDAPS IdP Auth - LDAP 4.x
REST API-based or Custom Ask your BlueFletch representative