TL:DR;
I have a trusted application within my VPC and I want to allow:
POST /oauth/authorize? user_id=U_123, client_id=xyz, client_secret=abdfd allows unlimited access to any user’s data on the assumption that client secret is secret. Is there precedence for that?
I have been implementing a Service Oriented Architecture and one of the pieces that I'm less confident about is our application authentication and authorization.
We have an internal application to the main API, which we have whitelisted for trusted OAuth using just the client credentials(id, secret) and the user id:
POST /oauth/authorize? user_id=U_123, client_id=xyz, client_secret=abdfd
Essentially, this makes it possible to generate an oauth token for a given user without password, and without displaying authorization page.
By including the user identifier in the mix, this allows user specific tokens, and gives us the option of invalidating tokens for a single user. In this way we don't have to invalidate the entire application, so potentially no compromise in the level of security.
Is there any precedence for a trusted client OAuth 2.0 token creation?
The use case you describe fits the Client Credentials grant as standardized in the OAuth 2.0 specification here: https://www.rfc-editor.org/rfc/rfc6749#section-4.4
The user identifier could effectively be passed in as a scope value which allows for accessing that user's (Resource Owner) resources. This is what the spec calls resources under control "of another resource owner that have been previously arranged with the authorization server".
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