We need to improve a system that delivers software updates (firmware/software files) to a Bluetooth device through a "companion" application installed on customers smartphones (ios/android).

The update process is implemented through calls to a REST API server (ASP.net, TLS 1.2) and being "userless" (but with different apps) we used OAuth2 with "client_credentials" flow, until now.

We used the "client_id" and "client_secret" couple to identify the caller application and then inject some claims into the bearer token, useful for example, to give different firmware to different applications. At the same time we used this system to prevent unauthorized API requests.

It works, but i never loved this system completely for various reasons, for example:

  • Without users, the token server doesn't create only overhead?
  • Storing client id and secret (in clear text) into mobile apps is secure?

I've read of API keys, but as this post says are not enough.

I think that we're "stretching" OAuth2 purposes to our needs, there are better ways to manage this?

1 Answer 1


Storing the client_secret in plain text is not a good idea, ios does enable data at rest encryption by default but for android you need to do some work yourself

As for the way you are using OAuth2 I can just say, it works for your use case. Perhaps this article will help you come to terms with your current set up, among the important parts it states:

"...one of the key reasons for OAuth2 to exist is so that Client applications do not need to collect user credentials (as they did with Basic authentication).

The Client has to obtain an access token, and to do that it has to be pre-registered with the Authorization Server, and it has to authenticate itself at the token endpoint.

So I would argue that, as per design and in terms of security, having to request the token is one of the strengths of OAuth2.

If you are looking for alternatives to deploy your software updates my opinion is that using the default app stores should be sufficient. An update does not need to be the most minimal piece of data needed to accomplish the business goal, it can be the same package as before with new data for use, what I mean is that your software update is the wrapper application which gets pushed to the app store and upon installation tries to push the updated data (not necessarily the entire app) to the bluetooth device.

  • Thanks for the advises, but being the client id/secret into apps source code i'm afraid that data protection techniques does not cover reverse engineering (see RFC link). I'm also afraid that issuing single client credentials for various client installations makes little sense (see RFC link) then i was looking for stronger alternatives. For the firmware part the update approach is interesting btw, but shipping a bundle of all the possible softwares perhaps is not feasible for us.
    – iRubens
    Feb 17, 2017 at 9:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .