Authentication and SSO

BlueFletch Launcher's optional Authentication module provides single sign-on (SSO) to devices by authenticating users through the customer's identity provider (IdP). This allows other applications to verify that authentication via the Launcher. The Auth module can be configured to require users to revalidate their authentication 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

When authenticating with OpenID or OAuth2 identity providers (IdPs), the Authentication module in BlueFletch Launcher uses Chrome Custom Tabs (CCT) to open a webpage and authenticate with the IdP. Once authenticated, the Auth module performs the code/token exchange to retrieve the access and refresh tokens, 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. The exchanged tokens and user information are temporarily stored in a shared token store, accessible via the 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

The Authentication module in BlueFletch Launcher can also act as an authentication broker for legacy applications that use a webview. After the user is successfully authenticated, the Auth module starts an HTTP server 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