<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">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">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">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!<br></div><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></div></div></div></div>