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

Nat Sakimura sakimura at gmail.com
Mon Jul 30 06:16:46 UTC 2018


Same here. If there really is a need, perhaps we can start contemplating a
way to do it.

On Mon, Jul 30, 2018 at 10:19 AM Brock Allen <brockallen at gmail.com> wrote:

> Suresh --
>
> Can you elaborate on your scenarios where a SPA (client-side browser based
> application) would need to maintain access tokens longer than the user's
> browser session?
>
> I'm very curious. Thanks.
>
> -Brock
>
> On 7/29/2018 6:38:29 PM, SureshAtt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> 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
> _______________________________________________ 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/20180730/6663cdad/attachment.html>


More information about the Openid-specs-ab mailing list