I am trying to implement a system for third-party apps to access data that a user stores on a provider. We have a robust access control system, with separate read/write/etc. levels for each "stream" of data published by a user. Inside our website, these access levels are already enforced depending on which user is trying to do which action with another user's stream.
Now comes time to allow third-party apps to do the same, in an oAuth2-compatible way. We currently represent third-party apps inside the provider app database as regular users with a user id, canonical url, etc. So this user id would be the client_id of the app.
My question is, why does oAuth have tokens at all, which are essentially opaque strings that map to (user_id, client_id) records that have (scope, etc)?
Can't the app simply identify itself with the client_id as its api key and sign its requests with a symmetric secret, for server-to-server requests? These signed requests and responses can be relayed through a user agent if need be, if there is an additional requirement that a user be online when the request is granted.
The provider already stores the access records for the (user_id, client_id) so it knows whether to approve or deny a request from the client app. Why does the client app need to store and spit back extra tokens?
The only thing I have come up with so far is maybe this is to increase the security in case someone gets unauthorized access to the client app's symmetric secret. And this way the attack would be limited to whatever tokens they would be able to get (since the tokens are required as an additional credential). Seems that on the server side, if someone gets the symmetric secret, they probably also get the database credentials as well. So this isn't much of a plus.
Is there any other reason? Or was it just security theater?