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.
- 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.
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.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
Package: com.bluefletch.ems.auth
Auth 3.x
IdP | Application Name |
|---|---|
LDAP | Auth - LDAP |
OKTA | Auth - OKTA |
Azure AD | Auth - MSAL |
ADFS | Auth - ADAL |
OKTA (REST) | Auth - OKTA Session |
Auth 4.x
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 | | |
Last modified 12h ago