[Openid-specs-ab] Hybird flow refresh tokens with javascript clients

Nat Sakimura sakimura at gmail.com
Sun Jul 29 00:32:20 UTC 2018


A public client can still use 'code' flow and that often is a recommended
way of dealing with OAuth.
A public client cannot get refresh token.

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.

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.)

Cheers,

Nat Sakimura

On Sun, Jul 29, 2018 at 7:31 AM SureshAtt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hello everyone,
>
> Is it expected that Javascript clients are allowed to get refresh tokens
> using hybrid flow?
>
> 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.
>
> However, the OAuth2 spec (section 10.4) says "*Refresh tokens MUST be
> kept confidential in transit and storage*". 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.
>
> 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.
>
> Thanks & regards,
> Suresh Attanayake
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180729/cbdecb4d/attachment-0001.html>


More information about the Openid-specs-ab mailing list