Hi team,
We are currently working on a Proof of Concept (PoC) for the Mobile Messenger SDK (MMSDK) focused on authenticated messaging feature.
Our approach is to obtain the access token and refresh token via Okta native SSO flow, and then passing these tokens to the Vault used by MMSDK. By doing this, we could avoid prompting the user a WebView to login by their username and password to get the auth code.
Token Authentication: If we manually pass the token to the Vault, will the user be authenticated to Genesys Cloud?
Custom Vault Integration: As mentioned in the Custom Vault section of the Transport SDK documentation, this can be done with the Transport SDK and we believe the MMSDK is built on top of it, is there a way to pass a custom Vault into MMSDK? If not, are there any plans to support this feature in MMSDK? If this is possible, please disregard question 3.
Vault Encryption on Android: Based on the source code, it appears that the Transport SDK uses a DefaultVault, which relies on standard SharedPreferences rather than an encrypted SharedPreferences. Could you confirm whether encryption is implemented for the Vault on Android SDK?
MessagingClient Access & Re authentication: The Mobile Transport SDK documentation states that MessagingClient.wasAuthenticated provides session persistence across app restarts. Additionally, the session can be configured without the authorization() step by calling messagingClient.connectAuthenticatedSession().
How can we access the MessagingClient object from MMSDK?
How does the re-authentication process work within MMSDK if MMSDK has got a valid refresh token?
We appreciate your time and assistance. Looking forward to your response.
At Web Messaging we use auth token flow. Meaning the user need to authenticate to your service not to Genesys. From Web Messaging point of view the auth token flow makes sure the user is authenticated and can use the secured channel.
The Mobile Messenger SDK doesn't provide access to custom Vault|
We don't have encryptions implemented on the Valut currently.|
If Transport has authToken stored in Vault from the past authorization - we will try configuring a session as Authenticated. If authToken is expired, we will try to refresh it using refreshToken and retry to connect to authenticated session again. If refresh token expired as well, we will throw an error asking user to re-authenticate. Thats in order to minimize the amount of login attempts required by the user. The wasAuthenticated field from Vault serves mostly for UI purpose to indicate if previous session was authenticated or guest (so the proper UI is drawn). |
The MessagingClient is not exposed from MMSDK, this is a private property. The MMSDK does not re-authenticate when the application restarts, it requires new AuthCode authentication on every restart.|
Is there a plan to allow Mobile Messenger SDK users to implement a custom Vault? This would address most of our requirements.
There are many capabilities within MessagingClient. For example, instead of obtaining a new authCode each time, we could call messagingClient.connectAuthenticatedSession(). Could we make MessagingClient accessible through the Mobile Messenger SDK?
I understand that the authorize() method requires an authCode, redirectUri, and codeVerifier for Genesys to exchange the token. Is there a plan to allow the client to authenticate itself (obtaining accessToken and refreshToken from our OpenID provider) and then pass them to the Mobile Messenger SDK for use?
Our expectations:
The Vault should be encrypted for better security. If a custom Vault is allowed for the Mobile Messenger SDK, the app can handle encryption itself.
Pass refreshToken and accessToken to the Mobile Messenger SDK via a method or custom Vault. Then, it should function similarly to the Transport you mentioned in your 4th point.
Thank you for your detailed explanation. Let me address your points and share my thoughts:
Backend Support:
As far as I know, at this point, our backend supports only the Web Application configuration of OIDC. I will check with the team regarding Native application support and create a POC with configurations matching your description.
Authorization Process and Postman Usage:
Technically speaking, when you call: MessagingClient.authorize(authCode: String, redirectUri: String, codeVerifier: String?),
the Transport SDK internally hits the exact same endpoint: https://api.mypurecloud.com.au/api/v2/webdeployments/token/oauthcodegrantjwtexchange.Once the token exchange is successful, we store only the refresh token. The access token is used to configure the authenticated session but is not stored due to its short lifespan.Given that the SDK uses the same endpoint, I’m curious why you opted to use Postman for token exchange instead of calling authorize directly. Could you elaborate on any specific challenges or limitations you encountered with using the SDK's authorization method?
Client Secret Removal:
You mentioned removing the client_secret. Do I understand correctly that you removed it from Okta Client Authentication configurations? If so, what option did you select instead—None or Public/private key?
Genesys OpenId Integration:
Typically, Genesys OpenId integration requires a client_secret during configuration. I’m interested in understanding how you're still able to obtain access and refresh tokens after removing the client_secret. Could you provide more details about your setup and how this works in practice?