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

SureshAtt suresh.attanayake at gmail.com
Sun Jul 29 21:22:46 UTC 2018


Hello Nat and David,

Thanks a lot for your replies. As David mentioned there is already a need
for SPA to get longer access to user resources and I have seen different
project solves this problem in different ways (ex: using iframes). This led
me to think if hybrid flow was desinged to handle this issue as well using
refresh tokens, but now I am clear it is not.

Thanks & regards,
Suresh Attanayake

On Sun, Jul 29, 2018 at 7:39 AM Nat Sakimura <sakimura at gmail.com> wrote:

> Thanks.
>
> I made a reply with too much haste as I was about to go out then but the
> point is this:
>
> As 10.4 of RFC6749 states:
>
>    The authorization server MUST maintain
>    the binding between a refresh token and the client to whom it was
>    issued.
>
>
> The most common and safe way of achieve it is to have
>
> the client authenticate to the authorization server.
>
> Thus, the client has to be a confidential client,
>
> i.e., the client that can keep the confidentiality of its key so that
>
> it can use a sender constrained tokens)
>
> effectively.
>
>
> (Note: RFC6749 does not define confidential client.
>
> Public client is defined slightly better but it still is sloppy like
>
> native applications are public client -- well, what if they did a dynamic registration
>
> to get a per-client secret? IMHO, these should be fixed.)
>
>
> So, getting back to Suresh's question, it is the intent of the authors not to allow the Javascript
>
> clients on a web browser to get refresh token. If the client is effectively a confidential client
>
> e.g., by using Token Binding, then, it in principle should be able to make use of a
>
> Token Bound refresh token, although, it kinds of infringes on RFC6749.
>
> I suppose the OAuth Token Binding spec should update that bit.
>
>
> Best,
>
>
> Nat Sakimura
>
>
>
>
>
>
>
> On Sun, Jul 29, 2018 at 12:36 PM David Waite <david at alkaline-solutions.com>
> wrote:
>
>> > On Jul 28, 2018, at 6:32 PM, Nat Sakimura via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>> <snip>
>> > 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.
>>
>> I’m not familiar with this restriction, my understanding is that it is
>> valid and in fact not uncommon for public clients to get and use refresh
>> tokens. RFC 6749 for example does not state such a restriction, and even
>> language around differing behavior with confidential clients vs public
>> clients:
>>
>>    "Because refresh tokens are typically long-lasting credentials used to
>>    request additional access tokens, the refresh token is bound to the
>>    client to which it was issued.  If the client type is confidential or
>>    the client was issued client credentials (or assigned other
>>    authentication requirements), the client MUST authenticate with the
>>    authorization server as described in Section 3.2.1”
>>
>> There are quite legitimate reasons for public clients to have refresh
>> tokens, and quite a few mobile apps which already are using refresh tokens.
>>
>> With SPA clients for instance, it allows you to extend access without
>> hidden Iframe tricks (and thus could be a workaround to ITP 2.0 blocking
>> state access on XHR / frames / non-interactive redirects, and such forms of
>> cross-domain access causing IDPs to be flagged as trackers)
>>
>> -DW
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>


-- 
Suresh Attanayake

Blog : http://sureshatt.blogspot.com/
Web : http://www.ssoarcade.com/
LinkedIn : http://www.linkedin.com/pub/suresh-attanayake/16/165/181
Twitter : http://twitter.com/sureshatt
Facebook : https://www.facebook.com/IdentityWorld
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180729/6ba3022c/attachment.html>


More information about the Openid-specs-ab mailing list