With Implicit flow it's usual to have a long expiration on access tokens as
there is no refresh token. Once the access token is expired you're left
with having to do the whole OAuth redirect dance again to obtain a new
token. What's even worse is that if you have long lived access tokens
there's potentially a longer time between the verification of
the access token directly with Keycloak, which means that an access token
could potentially be used long after the session has been removed.
With that in mind having short lived access tokens with a refresh token is
better in our opinion even for public clients.
On 12 July 2016 at 19:22, Josh Cain <josh.cain(a)redhat.com> wrote:
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
> <
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev