<div dir="ltr"><div>Using authorization code flow with public clients in Keycloak:<br></div><div><br></div><div>* Allows short expiration on access tokens</div><div>* Our JavaScript adapter doesn't store the refresh token and it's only kept in memory for the specific tab</div><div>* Refresh tokens are tied to a session which have idle timeout</div><div><br></div><div>Access token is set to expire in 5 min by default, but a lot of damage can still be done in 5 min so it needs to be kept secure. Refresh token is obviously worse as it, but by default the user session will expire if idle for 30 min so all refresh tokens will be invalid shortly after the user leaves the browser.</div><div><br></div><div>Google for instance issues an access token with 60 minutes expiration this is far worse than what we do in Keycloak as the token can't be revoked. Applications are not required to check with Google if the token is still valid, so there's a window of 60 minutes where it would be rather hard to block miss-use. It's actually common for social networks at least to issue fairly long expiration times (an hour or so) when using the implicit flow.</div><div><br></div><div>You could in theory use an embedded iframe to obtain a new access token once it's expired, but this is relatively tricky to get right as there's quite a lot of potentially vulnerabilities which is why we by default block all use of iframes. Any malicious injected code that manages to get the refresh token from the tab window would also be able to use the embedded iframe to obtain a new access token.</div><div><br></div><div>There is a spec that allows authenticating public clients. I couldn't find it right now, but probably something worth considering to add.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On 18 July 2016 at 19:19, Josh Cain <span dir="ltr"><<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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:<br><br></div>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:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Access Tokens might not be revocable by the Authorization Server.
Access Token lifetimes SHOULD therefore be kept to single use or
very short lifetimes. </blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
</blockquote><div><br></div>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?</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> </div><div class="gmail_extra"><span class=""><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><span><div><div>Josh Cain | Software Applications Engineer<br></div><i>Identity and Access Management</i><br></div><b>Red Hat</b><br><a href="tel:%2B1%20843-737-1735" value="+18437371735" target="_blank">+1 843-737-1735</a><br></span></div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">On Wed, Jul 13, 2016 at 1:37 AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>With that in mind having short lived access tokens with a refresh token is better in our opinion even for public clients.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 12 July 2016 at 19:22, Josh Cain <span dir="ltr"><<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div>Hi All,<br><br></div>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 <a href="https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.0/topics/oidc/javascript-adapter.html" target="_blank">your docs</a> that the Javascript adapter is intended for client-side use:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Keycloak comes with a client-side JavaScript library that can be used to secure HTML5/JavaScript applications. <br></blockquote><br></div>The docs also state that the default flow for this adapter is the Authorization Code flow:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">By default, the JavaScript adapter uses the <a href="http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth" target="_blank">Authorization Code</a> flow.<br></blockquote><br></div>However, the <a href="http://openid.net/specs/openid-connect-core-1_0.html" target="_blank">OIDC spec</a> says (section 3.1):<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">...The Authorization Code flow is suitable for Clients that
can securely maintain a Client Secret between themselves and the
Authorization Server.
<br></blockquote><div><div><div><div><br></div><div>And again echoes the sentiment using the non-requisite MAY language in section 15.4:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br></blockquote><br></div><div>I'm aware that public clients who do not present a client secret are allowed under the <a href="https://tools.ietf.org/html/rfc6749" target="_blank">OAuth spec</a>, 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.<br><br></div><div>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 <i>not</i> be implicit here? Could you help me understand why the authorization code flow was chosen as the default?<br><br></div><div>Thanks in advance!<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><span><div><div>Josh Cain | Software Applications Engineer<br></div><i>Identity and Access Management</i><br></div><b>Red Hat</b><br><a href="tel:%2B1%20843-737-1735" value="+18437371735" target="_blank">+1 843-737-1735</a><br></span></div></div></div>
</div></font></span></div></div></div></div>
<br></div></div>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div></div>