One of the biggest hurdles with an on-premise installation is the need to register the application (explained further below in Beginning OAuth) with each API provider that supports OAuth (for example, 1.0, 1.0a, 2.0). When we talk about a single installation, the registration process tends to be straightforward, and managing multiple registrations for a single app is relatively uncomplicated. Nevertheless, if there’s a need to manage many registrations for many installations then it is easy to see how managing registrations can quickly become a problem in scalability and security.
Another hurdle with on-premise installation is the differing procedures for creating developer accounts with the API provider. In order to begin registering a client application for OAuth authorization, sometimes it is necessary to create an account for the API that we are trying to access. The requirements for creating this type of account is provider specific. Sometimes the process can be as simple as providing an email, other times, access is guarded by a pay-wall, and sometimes API access is divided into levels for which the consumer must gradually be “upgraded” to achieve full unrestricted access (less common).
As far as the OAuth implementation recommendations are concerned, any redirect URI that receives sensitive information is NOT required to be secure (i.e encrypted), nevertheless, TLS is recommended. Most 3rd party API’s make this a REQUIREMENT, in which case all on-premise installations must properly configure the hosting server (IIS) for secure connections via TLS.
Lastly, some 3rd party API’s will only allow the domain name of a given redirect URI to end with a public top-level domain (TLD) such as .com or .org. In this case, any server installation that cannot be reached via a URI with a compatible domain name, will need to have its bindings altered accordingly, that is, so that it can be reached via a URI that ends with public TLD.