And again echoes the sentiment using the non-requisite MAY language in section 15.4:
In general, it is up to Relying Parties which features they use
when interacting with OpenID Providers.
However, some choices are dictated by the nature of their OAuth Client,
such as whether it is a Confidential Client, capable of keeping secrets,
in which case the Authorization Code Flow may be appropriate,
or whether it is a Public Client, for instance, a
User Agent Based Application or a statically registered Native Application,
in which case the Implicit Flow may be appropriate.
I'm aware that public clients who do not present a client secret are allowed under the
OAuth spec, and that these are often the type of javascript client that Keycloak sets up with the authorization code flow. What's more, I understand that the client secret is most commonly the reason cited for the client/server distinction with respect to flows.
However, I was curious as to why the authorization code flow remains the default setting for Javascript applications. Isn't the refresh token also considered a form of a 'secret' since it's a long-lived mechanism whereby additional access/identity tokens can be retrieved? Why would the default setting not be implicit here? Could you help me understand why the authorization code flow was chosen as the default?
Thanks in advance!
Josh Cain | Software Applications Engineer
Identity and Access Management Red Hat
+1 843-737-1735