<div dir="ltr">A public client can still use 'code' flow and that often is a recommended way of dealing with OAuth. <div>A public client cannot get refresh token. </div><div><br></div><div>Assuming that you mean "a client working within a browser using JavaScript" by "a JavaScript Client" since it is a public client, it cannot get a refresh token. </div><div><br></div><div>Many people seem to equate using code grant type with a confidential client but that is not the case. That's not the case. Whether it is a confidential client or a public client depends upon its ability to keep the secret confidential. (This is a topic in my youtube video coming up in two weeks.) </div><div><br></div><div>Cheers, </div><div><br></div><div>Nat Sakimura</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 29, 2018 at 7:31 AM SureshAtt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hello everyone,</span><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Is it expected that Javascript clients are allowed to get refresh tokens using hybrid flow?  </span><br><div><br></div><div>According to the OIDC spec and to the Multiple Response Types Encoding Practice spec, in the hybrid flow the authoriation code by default is returned with fragment encoding (query encoding must not be used). This means a Javascript client can get hold of the authorization code and use it to get a refresh token. With this refresh token, the Javascript client can keep refreshing access tokens using the "none" client authentication mechanism. </div><div><br></div><div>However, the OAuth2 spec (section 10.4) says "<i>Refresh tokens MUST be kept confidential in transit and storage</i>". But Javascript clients are by nature public clients which are unable to keep the refresh tokens confidential. And neither OIDC spec security considerations section nor the OAuth2 Threat Model spec cover the case where the refresh tokens are stored in a JS client, for example against tampering the refresh token stored in the local storage. </div><div><br></div><div>Therefore I am not clear if it is expected to use refresh tokens with Javascript clients or not. Please help me to clearify this point. </div><div><br></div><div>Thanks & regards,</div><div><div dir="ltr" class="m_-7674533494959795874gmail-m_589810328701156715gmail_signature">Suresh Attanayake</div></div></div><br></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div></div>