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

Jeff LOMBARDO jeff.lombardo at gmail.com
Mon Jul 30 19:33:45 UTC 2018


Hi Suresh,

What end user typology are we talking about here? Most of the time the "I
don't want to have my user to sign-in again" is solved through transparent
authentication / WebSSO, not long applicative session... For example, if we
are talking about Employee on Managed devices, a Kerberos / IWA on the
first mile on the OP sign-in page should solve your case.

My poor two cents.

JF

Le lun. 30 juill. 2018, à 07 h 38, SureshAtt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> a écrit :

> Hi Brock,
>
> In our organization I came across with couple SPA having the requirement
> that they want to prevent the redirect to IdP after user's first log in.
> That is somehow a keep-me-signed-in like behavior. Ofcouse it is stright
> forward if the client was confidential. However, since the requirement
> showed up couple of times, I questioned my understanding of the hybrid
> flow. Therfore I ended up with the questions above.
>
> Thanks,
> Suresh Attanayake
>
> On Mon, Jul 30, 2018 at 3: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
>>
>>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180730/e9fc5d9d/attachment-0001.html>


More information about the Openid-specs-ab mailing list