1

I'm currently building an Android app that uses OAuth to sign in to a service. With OAuth, I need to provide a client ID and a client secret to the service so it can identify my app. Right now, I'm storing the credentials like this:

public class Creds {
    public static final String CLIENT_ID = "THE_CLIENT_ID";
    public static final String CLIENT_SECRET = "THE_CLIENT_SECRET";
}

Obviously, this is not secure at all. Anyone can just decompile the APK file and see the strings instantly. How can I prevent people from doing so?

I wouldn't consider an obfuscator an acceptable solution since anyone who goes through enough effort can still recreate the strings.

note: This is not a dupe of this question since that discusses how to keep strings out of source control, not hide them inside the APK file. For example, a configuration file containing the keys could be kept out of source control but present in the decompiled APK.

edit: What if I put the strings in native code and retrieved them via JNI? Native code is much harder to decompile.

Improve this question
2

1 Answer 1

Reset to default
11

Why is it holding the secret? The app should never be holding the secret.

Your back end (or the validation service you're using) for performing the authentication round trip should be holding the secret and nothing else should ever contain it. The client ID needs to be available for the user, it's what they use to know what they're authenticating for so that's necessary for them to be able to view.

Yet again; the secret is secret and you should never give your users the chance to even catch a glimpse of it. If you do anyone can pose as you.

Improve this answer
4
  • Are you sure that you know how OAuth works with respect to the client secret? I think it's reasonable to include it, with some obfuscation methods, in an app binary. I would not, however, rely on the client credentials grant type for a mobile app.
    – RibaldEddie
    Commented Jul 10, 2017 at 22:08
  • 1
    @RibaldEddie Yes I am sure but you are free to cross-check my information. security by obscurity is not security. You're not keeping the secret safe through obfuscation. To understand whether or not it's reasonable to include it you have to make your own assessment, it's your risk calculation to make, but I would personally never include it in any way or form. See also the answer Jacob Hull referred to.
    – Robzor
    Commented Jul 11, 2017 at 7:46
  • Not everything that is a "secret key" is the same. A secret API key is not the same as a "client secret" in the context of OAuth. The alternative is no or a blank secret and in the context of an OAuth client that is a native app, I would say it's better to have a random value as a secret than none at all. The only caveat is to be aware of the different grant types and to ensure that you have the ability to limit the authorized grant types on a per client basis and not to allow the use of any grant type such that the client key and secret are exclusively sufficient for gaining access.
    – RibaldEddie
    Commented Jul 12, 2017 at 21:35
  • 1
    I think it's pretty clear that a native mobile app available through an App Store is a legitimate use of a secret and Id. In combination with a password grant it seems very reasonable.
    – RibaldEddie
    Commented Jul 13, 2017 at 2:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.