OAuth2 Authentication (auth_oauth): "Implicit Flow" vs. "Authorization Code Flow"

[ghost]

"Implicit Flow" is used in scenario where more appropriate choice is the "Authorization Code Flow"

Impacted versions:

• 14.0 (probably all the previous ones as well)

Steps to reproduce:

1. Use the "OAuth2 Authentication" (auth_oauth) module

Current behavior:

• "Implicit Flow" is used in the auth_oauth

Expected behavior:

• "Authorization Code Flow" being used in the auth_oauth

Detailed Description of the Issue:

It seems like we are mixing apples and oranges by using the scenario
designed for the Client-side applications in the web server application.
Namely, the official "OAuth2 Authentication" (i.e. the auth_oauth) module
of Odoo uses the "Implicit Flow"(1), which is a more appropriate for
Client-side (JavaScript) applications(3), while the "Authorization Code Flow"(2)
should be used as a more appropriate option for the Web server applications(4).

Interestingly, relevant Google documentations linked above does not explicitly
mention "Implicit Flow" and "Authorization Code Flow" (or I failed to notice those words),
but instead uses titles "Client-side (JavaScript) applications" and "Web server applications"
respectively, but from the diagrams/descriptions one might easily see
which is "Implicit Flow" and which is "Authorization Code Flow", although
usage of those terms is avoided, probably in an effort to promote correct
choice of relevant flows in the relevant use cases.

For an extra clarity, "Implicit Flow" reffers to the scenario, where
the response_type=token is used in the initial token request, and
the "Authorization Code Flow" refers to the scenario, where the
response_type=code is used instead.

Taking into the account that "OAuth2 Authentication" (auth_oauth) module
acts in the context of web server rather than client-side application, it
should be definitely using "Authorization Code Flow"(2) (or "Web server applications"
version of Oauth 2.0 in terms of Google documentation(4)), instead of
the "Implicit Flow" used currently.

Besides, the existing "Implicit Flow" implementation in the auth_oauth module has
a few open issues, like #63963, #63964 and #63750. Additionally some more
Oauth issues are open, which might possibly be related as well. Instead of solving
all of those issues in the current "Implicit Flow" implementation, I would suggest
to switch completely to the "Authorization Code Flow", and only ever use "Implicit Flow"
when/if there will be a real need for it, i.e. when some client side (javascript) code will
be directly interacting with the Oauth2 provider, but in case of the
"OAuth2 Authentication" (auth_oauth) module it is not the case, as it
interacts with the providers from the server side code, so, it is better to stick
with the "Authorization Code Flow" option (AKA "Web server applications" option).

[psztoch]

You are right.
implicit flow is not as secure as should be.
OpenID Connect is popular and good standard, and should be properly implemented in odoo.
https://accounts.odoo.com/oauth2/auth should be investigated for security issue too. This oauth2 server should properly verify nonce token.

[sbidoul]

People interested in this issue may want to look at auth_oidc in OCA (OCA/server-auth#261), which implement OpenID Connect with authorization code flow (with PKCE and client_secret basic auth).