With OAuth the ClientID and redirect_url have a strong connection: You need a seperate ClientID for each redirect_url. This is a problem for on-premise applications which have multiple deployments in multiple domains.
Is there any way to implement OAuth authentication from an unknown domain? The only alternative I could come up with requires a dedicated "authentication server" at a fixed domain which can be used as the redirect_url and can then perform a new, unrestricted, redirect to the customer domain.
Desktop applications work around this by supplying a dummy redirect_url and then hosting the live authentication window in a dedicated web frame which lets them listen to the redirect requests. This allows them to read the authorization code from the redirect URL even if the URL itself isn't valid. I believe this isn't possible in web browsers due to cross-domain restrictions.
Essentially OAuth would be needed for supporting SkyDrive publishing in an on-premise web application.
The redirect URI is the callback entry point of the app. Think about how OAuth for Facebook works - after end user accepts permissions, "something" has to be called by Facebook to get back to the app, and that "something" is the redirect URI.
A callback URL is the URL that is invoked after OAuth authorization for the consumer (connected app). In some contexts, the URL must be a real URL that the client's web browser is redirected to.
RFC 6749 (OAuth 2.0) states that the Authorization Server must require the redirect_uri to be pre-registered for Public Clients but not for Confidential Clients, as long as they are not using the Implicit Grant. Depending on whether you provide your Client Credentials with the installation or the system admin enters their own Client Credentials your system would end up in different categories. It is however recommended by the RFC to always require a pre-registered redirect_uri so you would most likely have the same problem with either categorization.
I'd say that the only solution viable for you is to require that the system admin of the system supply their own Client Credentials when configuring the system. If they supply their own Client Credentials they would also need to register their own redirect_uri with the Authorization Server, and the problem is thereby solved.
You should not implement an intermediary Authentication Server because that would open up the security of your application. If a user authorizes one installation of your system they will automatically authorize all installations which in turn can make their personal data available to other organizations than the ones they have authorized.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With