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

[Josh Cain]

Thanks for the quick response Stian!  Still getting my feet wet with OIDC,
so please bear with me as I try to reconcile what I'm reading @ the spec
with the Keycloak implementation.  A few questions on your response:

You say that it's 'usual' for these access tokens to have a long lifespan
with implicit flow.  How does that interact with the general guideline in
section 16.18 of the spec when it says:

Access Tokens might not be revocable by the Authorization Server. Access
> Token lifetimes SHOULD therefore be kept to single use or very short
> lifetimes.


I would agree that a long-lived refresh token is indeed much preferred to
doing something like extending the lifetime of an access token.  However,
is 'the OAuth redirect dance' the only alternative?  I know that Keycloak's
identity/session cookies will have been issued at this point - would it be
possible to use something like an iFrame to refresh a short-lived access
token?

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735

On Wed, Jul 13, 2016 at 1:37 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> 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 at 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/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
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160718/603a119d/attachment-0001.html