Authentication and SSO
Last updated
Last updated
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.
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
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.
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.
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.
Package: com.bluefletch.ems.auth
Auth 3.x
To find the latest application binary versions, see the BlueFletch Portal Downloads page.
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.
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
