Using the optional Authentication module, Launcher provides single sign-on to the device by authenticating the user through the customer’s identity provider and allows other applications to verify authentication via the Launcher.
Supported Identity Providers
- Integration with Zebra's Ptt Pro
|Okta||OpenId||App Auth||Ping, Okta, OneLogin||Chrome Custom Tab support|
|OktaRest||OpenId||App Auth||Ping, Okta, OneLogin||Native Token|
|ADAL||OAuth2||ADAL||ADFS 3.0, Azure AD 1.0||Native Token Support|
|LDAP||LDAP||Unbound||ADFS 2.0+, LDAP||Native Token Support|
The following are available secondary methods for re-authentication
- Face Verification
- NFC Tag
For OpenID or OAuth2 IDPs, the Launcher’s Login app authenticates with the IDP via a webpage using Chrome Custom Tabs (CCT).
Once authenticated, the Login app 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 + user information is temporarily stored in a shared token store, accessible via EMS 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.
Authentication Broker for Legacy Apps
Optionally, for Legacy applications that use a Webview, after the user is successfully authenticated, the Login app 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 it’s 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.