Tweeted twitter.com/StackSoftEng/status/1042156522913054720
2 clarified reason for asking - we want third parties to pay us to make new apps that use our APIs
source | link

Goal: Prevent unauthorized 'clone' apps from using REST API-based solutions where the customers manage their own servers and services instead of the vendor doing so (database, resource, and identity). In other words: on-premise servers instead of a cloud-based solution.

My company wants to be able to authorize only some third-parties to be able to create apps that can use our APIs, but not just anybody, in addition to our own apps. So we will likely have some process where third parties will submit their apps to us for signing and adding to some kind of 'white-list' (whatever form that ends up taking.. hence the question.)

(Why no cloud? Some countries and industries are subject to stricter regulations where cloud or off-site servers is not an option for some classes of sensitive operational data. If that is not good enough of a reason, then please consider this a thought experiment).

This question is a variation on this near identical question, but with the additional constraint that the software vendor doesn't own or manage the servers.

I have zero affiliation with CodeBlue, the makers of Approov, but they did publish a decent explanation of the typical process for securing REST APIs for both web apps and mobile apps. Here is a link to part 2 of 3 which covers some of the critical points such as the mediation server and the attestation process for authorizing the client and techniques for keeping shared secrets out of public clients (i.e.: mobile apps).

https://www.approov.io/blog/mobile-api-security-techniques-part-2.html

The solution described by the above article from CodeBlue sounds dandy for a cloud-based or vendor-controlled environment. However, I have been struggling to find a way to protect against clone apps when the customer has physical access to not only the clients, but to the servers. Configuration alone could probably enable unauthorized apps, and if that doesn't work the app itself could be modified.

Of course there is a legal safety net here (license agreement, terms of service), but is there anything code-wise that can be done to harden against this, if not prevent it outright?

I am aware of - and pursuing - various techniques for obfuscating solutions (like spreading the secrets around, and protecting against reverse engineering) and for client attestation, but in all of my models so far there exists the possibility that a malicious customer (or agent) can trick the REST API into believing that requests are made by an authorized client. I know I'm in some kind of arms race here - so I'm reaching out to the community for thoughts on this because all of the methods I have researched over the past week rely on the vendor owning the server.

Goal: Prevent unauthorized 'clone' apps from using REST API-based solutions where the customers manage their own servers and services instead of the vendor doing so (database, resource, and identity). In other words: on-premise servers instead of a cloud-based solution.

(Why no cloud? Some countries and industries are subject to stricter regulations where cloud or off-site servers is not an option for some classes of sensitive operational data. If that is not good enough of a reason, then please consider this a thought experiment).

This question is a variation on this near identical question, but with the additional constraint that the software vendor doesn't own or manage the servers.

I have zero affiliation with CodeBlue, the makers of Approov, but they did publish a decent explanation of the typical process for securing REST APIs for both web apps and mobile apps. Here is a link to part 2 of 3 which covers some of the critical points such as the mediation server and the attestation process for authorizing the client and techniques for keeping shared secrets out of public clients (i.e.: mobile apps).

https://www.approov.io/blog/mobile-api-security-techniques-part-2.html

The solution described by the above article from CodeBlue sounds dandy for a cloud-based or vendor-controlled environment. However, I have been struggling to find a way to protect against clone apps when the customer has physical access to not only the clients, but to the servers. Configuration alone could probably enable unauthorized apps, and if that doesn't work the app itself could be modified.

Of course there is a legal safety net here (license agreement, terms of service), but is there anything code-wise that can be done to harden against this, if not prevent it outright?

I am aware of - and pursuing - various techniques for obfuscating solutions (like spreading the secrets around, and protecting against reverse engineering) and for client attestation, but in all of my models so far there exists the possibility that a malicious customer (or agent) can trick the REST API into believing that requests are made by an authorized client. I know I'm in some kind of arms race here - so I'm reaching out to the community for thoughts on this because all of the methods I have researched over the past week rely on the vendor owning the server.

Goal: Prevent unauthorized 'clone' apps from using REST API-based solutions where the customers manage their own servers and services instead of the vendor doing so (database, resource, and identity). In other words: on-premise servers instead of a cloud-based solution.

My company wants to be able to authorize only some third-parties to be able to create apps that can use our APIs, but not just anybody, in addition to our own apps. So we will likely have some process where third parties will submit their apps to us for signing and adding to some kind of 'white-list' (whatever form that ends up taking.. hence the question.)

(Why no cloud? Some countries and industries are subject to stricter regulations where cloud or off-site servers is not an option for some classes of sensitive operational data. If that is not good enough of a reason, then please consider this a thought experiment).

This question is a variation on this near identical question, but with the additional constraint that the software vendor doesn't own or manage the servers.

I have zero affiliation with CodeBlue, the makers of Approov, but they did publish a decent explanation of the typical process for securing REST APIs for both web apps and mobile apps. Here is a link to part 2 of 3 which covers some of the critical points such as the mediation server and the attestation process for authorizing the client and techniques for keeping shared secrets out of public clients (i.e.: mobile apps).

https://www.approov.io/blog/mobile-api-security-techniques-part-2.html

The solution described by the above article from CodeBlue sounds dandy for a cloud-based or vendor-controlled environment. However, I have been struggling to find a way to protect against clone apps when the customer has physical access to not only the clients, but to the servers. Configuration alone could probably enable unauthorized apps, and if that doesn't work the app itself could be modified.

Of course there is a legal safety net here (license agreement, terms of service), but is there anything code-wise that can be done to harden against this, if not prevent it outright?

I am aware of - and pursuing - various techniques for obfuscating solutions (like spreading the secrets around, and protecting against reverse engineering) and for client attestation, but in all of my models so far there exists the possibility that a malicious customer (or agent) can trick the REST API into believing that requests are made by an authorized client. I know I'm in some kind of arms race here - so I'm reaching out to the community for thoughts on this because all of the methods I have researched over the past week rely on the vendor owning the server.

1
source | link

How to safeguard a COTS REST API with on-premise servers for approved client apps only?

Goal: Prevent unauthorized 'clone' apps from using REST API-based solutions where the customers manage their own servers and services instead of the vendor doing so (database, resource, and identity). In other words: on-premise servers instead of a cloud-based solution.

(Why no cloud? Some countries and industries are subject to stricter regulations where cloud or off-site servers is not an option for some classes of sensitive operational data. If that is not good enough of a reason, then please consider this a thought experiment).

This question is a variation on this near identical question, but with the additional constraint that the software vendor doesn't own or manage the servers.

I have zero affiliation with CodeBlue, the makers of Approov, but they did publish a decent explanation of the typical process for securing REST APIs for both web apps and mobile apps. Here is a link to part 2 of 3 which covers some of the critical points such as the mediation server and the attestation process for authorizing the client and techniques for keeping shared secrets out of public clients (i.e.: mobile apps).

https://www.approov.io/blog/mobile-api-security-techniques-part-2.html

The solution described by the above article from CodeBlue sounds dandy for a cloud-based or vendor-controlled environment. However, I have been struggling to find a way to protect against clone apps when the customer has physical access to not only the clients, but to the servers. Configuration alone could probably enable unauthorized apps, and if that doesn't work the app itself could be modified.

Of course there is a legal safety net here (license agreement, terms of service), but is there anything code-wise that can be done to harden against this, if not prevent it outright?

I am aware of - and pursuing - various techniques for obfuscating solutions (like spreading the secrets around, and protecting against reverse engineering) and for client attestation, but in all of my models so far there exists the possibility that a malicious customer (or agent) can trick the REST API into believing that requests are made by an authorized client. I know I'm in some kind of arms race here - so I'm reaching out to the community for thoughts on this because all of the methods I have researched over the past week rely on the vendor owning the server.