0

So according to the resources found here and in the official protocol documents I have a good grasp on what flow-types to use for what client-type. According to the following picture (credit: https://alexbilbie.com/guide-to-oauth-2-grants/):

Credit: https://alexbilbie.com/guide-to-oauth-2-grants/

Note: I know Password Grant & Implicit grant are deprecated I replaced them with their better counterparts in my metal model.

Here's my question, does anything change if our software, which is/will be the OAuth Provider can be installed as an on-prem software running in a private cloud. Say a company buys our software and installs on-prem and sets it up serving as an OAuth Provider. They might digest our oauth protected API with various Client types (desktop application, web application running in the same private cloud, whatever).

I'm just interested that the fact that they have the OP (oauth provider) and the Client on the same virtual domain/private cloud/etc will change the flow-type they should choose.

With a practical example

A native desktop client is considered a public client in oauth because such a client can't keep the secret safe. In a situation which I'm asking about a company might install this desktop client to the workstations and install our software on their own cloud, so there is an inherent trust between the parties now. Should they use any other flow in their desktop client other than the advised Authorization Code grant with PKCE just because they are now considered a confidential client?

We, as the service providers/software vendors just want to give educated proposals for our clients on what oauth flow they would want to use, however I don't know what to tell those customers in case they are on-prem.

Disclaimer: I'm just a regular developer who is responsible to integrate oauth to our system

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.