7:22 p.m.
Hi All,
We're looking to start rolling the Keycloak OIDC flow out to some
client-side Javascript applications, and I came across a question in coming
up to speed on OIDC. You state in your docs
<https://keycloak.gitbooks.io/securing-client-applications-guide/content/v...
that the Javascript adapter is intended for client-side use:
Keycloak comes with a client-side JavaScript library that can be used to
secure HTML5/JavaScript applications.
The docs also state that the default flow for this adapter is the
Authorization Code flow:
By default, the JavaScript adapter uses the Authorization Code
However, the OIDC spec
<http://openid.net/specs/openid-connect-core-1_0.html> says (section 3.1):
...The Authorization Code flow is suitable for Clients that can securely
maintain a Client Secret between themselves and the Authorization
Server.
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 <https://tools.ietf.org/html/rfc6749>;, 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