Generally speaking we can specify the potential risk into 2 categories: user-agent risk and client server risk.
As for the 3 client types mentioned in section 2.1 of the Oauth 2.1 draft (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03), only the “web application” may encounters both the 2 risks, while the others (“browser-based application” and “native application”) only have user-agent risk.
user-agent risk: The user-agent environment (browser, app, or the OS they are running) may be not safe. Especially when the client has huge users the probability of this risk is relatively higher.
client server risk: Usually the client server is much more safe than user-agent, so the probability of leaking the access tokens stored in the web server is low.
However if we consider the overall “expectation of loss” for these 2 risks, it’s not sure if the
E(S)(expectation of loss for client server risk) is always lower than the
E(U) (expectation of loss for user-agent risk).
E(S) = P(S) * L(S) and E(U) = P(U) * L(U), where
P() means the probability of each risk, and
L() means the potential loss if each risk event happens.
As mentioned above the
P(S) is much less than
P(U) usually, however the
L(S) is also much higher than
L(U). Assuming a client server is hacked or some bad guys inside the client broken the server, all the users’ access tokens stored on the server will leak and the potential loss
L(S) will be much higher. Instead in the user-agent risk scenario, the
L(U) would be smaller because just access tokens of some individuals leak.
Especially if we build a fully open platforms through Oauth schema, the
P(S) may be not so small because the authorization / resource server owner cannot guarantee each of (we application) client is trusted.
So the questions is: Does it prefer to avoid client server risk rather than the user-agent risk in the latest trend? As we see the authorization code grant is extended with the functionality from PKCE? The PKCE flow can be done from the pure browser / app end (even for the we application client) completely, the server side is not must involved and it cannot store the access tokens then.
Instead in the Oauth 2.0 (RFC 6749, 6750) the authorization code flow has to involve the server side when fetching the access token, because it is dangerous to expose the “client secret” to the user-agent browser / app.
Not sure if this understanding is correct, and could you kindly give some more suggestions for the trade-off between user-agent risk and client server risk when building an Oauth based platform?