Our service uses OAuth to issue refresh-tokens that 3rd-party applications can later use to access users' resources without the presence of the user (server to server). We currently use Authorization Code flow and require the apps' developers to store refresh tokens per each user on their side, and use the refresh token to generate a short-lived access token that they can then use to access the user's resources. This works fine.
However, implementing this flow isn't easy for app developers. They have to implement all required redirects, and store many tokens securely on their side.
I'm trying to understand if the following approach has any security or other flaws that I miss:
Basically this approach eliminates the need to manage refresh tokens by the clients, and the need to implement all the different redirects implied by oauth. In addition, it allows tokens revocation very easily, because all grant-consents are stored on the authorization server.
Do I miss anything? Any reason not to use this approach?
Note: This question is similar, but it asks about an internal super-powered app.
I would advise against this approach. There really isn't any benefit, and it's extremely risky to try and invent your own security process rather than something that's an established standard with countless people using and evaluating it.
The motivation is completely understandable. The devs are struggling with oauth because everyone does. But things like redirects are intentionally put in place for security.
There are several things here that will put your security at greater risk.
There is no user in a client credentials flow. The client authenticates with the authorization server and then gets a token back.
In step 1, you've opened up the attack vector significantly by not requiring the user to re-auth. You've essentially created an unexpiring refresh or access token (except for requiring the client to authenticate rather than just being the bearer of a token). And storing this info binds the user with the client id. If anyone else happens to use the app, there'll be no way for you to know.
Refresh tokens are a convenience to avoid asking the user to re-auth. You've still got the same number of redirects in your approach. In step 3, you've only traded out one thing for another. They have to store this info.
There are a few other things, but even if this did look solid without any holes, you're not getting the benefit of a large community continuously testing and updating it when any vulnerabilities are discovered. And the attack landscape is constantly evolving.