Confused about which type of OAuth2 flow to implement for our web app to web app communication

Question

We have a small .NET MVC legacy website that we are trying to implement OAuth2 for.

Here's how it currently works:
The website has no user accounts. So, no login is required - no authentication is performed. Instead GET Requests are sent to a controller method. These GET Requests consist of encrypted parameters, which are received, decrypted, and then a webpage is displayed. The "client" (a wep app) that sends these GET Requests has a unique encryption key and IV that we provided to them. Of course we trust them to keep this information "secret". If there is an actual Resource Owner in this scenario, it seems that it would be the actual "client app" that the request is coming from.

Alas, the time has come to make this process a little more secure. There are many articles about OAuth2 Flows and the Client Credentials flow seems like it would fit this use case, but typically the information regarding this flow suggests that the "client app" is "trusted", and the implication of "trust" is that we actually also own the "client app". Well, we don't own the client app which makes me question if this is really the right flow for this use case. Every other OAuth2 flow seems to best fit accessing the resources of a Resource Owner that tends to be a user with a username and password. We don't have any actual user accounts to authenticate usernames and passwords for, leading me right back to Client Credentials flow.

Furthermore, we haven't been able to find any examples that are similar to our particular use case, which is basically web app to web app communication where the client web app is not owned by us. After reading this article: Consuming own API for web app - Authentication process with OAuth2, where the Client Credentials flow is not recommended, we're wondering which flow would be recommended.

For the use case described above, which OAuth2 flow do you think would work best?

Answer 1

app to app is pretty simple. I will refer you to an older article I wrote on the subject a while ago : https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/. The article is pretty long and convers a lot hence why I don't just paste some stuff here.

All you need really is to protect your Resource Server and you can issue each client app with their unique ClientID / CLientSecret and that's what they'll use to authenticate themselves.

Your clients will be responsible for keeping their ClientID and Secret private, of course.