[keycloak-dev] Authorization Code Flow as Default for Javascript?

Josh Cain josh.cain at redhat.com
Tue Jul 12 13:22:31 EDT 2016


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/2.0/topics/oidc/javascript-adapter.html>
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
> <http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth> flow.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160712/712b0e44/attachment.html 


More information about the keycloak-dev mailing list