Use Client-side ID rather than Mobile Key

[theboyknowsclass]

Hi, our Security team have raised a question about whether we can use the Client-side ID instead of the Mobile API Key as we are worried about the decompilation of our c# code exposing the key.

Do you have support for this / is it on a roadmap?

kind regards

Gautam Bhatnagar

[bwoskow-ld]

Hi @theboyknowsclass,

A "mobile key" is not considered confidential. As such there is minimal risk if it is exposed in a decompiled application. In general, we do not recommend embedding any secrets (for LaunchDarkly or otherwise) in binaries which are distributed onto customers' own devices for this very reason.

I recommend that you take a look at our documentation on this topic. A mobile key grants read-only access to evaluated values of feature flags which were opted into scope for mobile evaluation. The three italicized items are worth emphasizing: mobile keys do not grant 1) write access to flags, 2) read access to targeting rules, or 3) read access to flags which were not explicitly enabled for mobile evaluation. At a higher level, mobile keys can be understood to only grant access to the specific sets of functionality that mobile SDKs offer -- nothing more -- and only for flags opted into for mobile evaluation.

For these reasons we do not have any plans to change this SDK to use a client-side ID instead of mobile key.

If you ever have specific concerns about a mobile key getting exposed we offer the ability to rotate the key, however, please note that doing so would affect any active customers using that mobile key with your software.

I'm going to close this task, but let me know if you have any further questions.

Cheers,
@bwoskow-ld

[theboyknowsclass]

hi @bwoskow-ld thanks for the quick response! sorry one question is the difference between Client-side Id and Mobile API key in terms of data exposed is just the scoping?

[bwoskow-ld]

Great question. To be frank, there's little difference in client-side IDs and mobile keys these days. Several years ago, when LaunchDarkly initially rolled out server-side and client-side SDKs, the distinct differences between the three kinds of identifiers (those two plus SDK keys) was:

1. SDK keys could access flag targeting rules, thus exposing potentially sensitive business rules or customer identifiers
2. Mobile keys could not access flag targeting rules and instead could only access evaluated flag values for a particular user, and could do so for all flags associated with the corresponding environment
3. Client-side ID similarly could only access evaluated flag values for a particular user, but only for a subset of an environment's flags as denoted by whichever flags are opted into client-side evaluation

At that time there was a notable difference between #2 and #3 (all flags versus a subset), and as a result LaunchDarkly added the ability to rotate a mobile key.

Then, last year, we improved our security / access control capabilities by expanding the opt-in functionality to SDKs using mobile keys. It was no longer the case that mobile keys would always have access to all flags in the corresponding environment. By this time the two identifiers are effectively the same, except for the fact that mobile keys can still be reset, whereas client-side IDs cannot be.

Cheers,
@bwoskow-ld