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

SureshAtt suresh.attanayake at gmail.com
Mon Jul 30 19:42:22 UTC 2018


Hello Jeff,

In this case users are the end customers, so basically those are B2C web
applications.

-Suresh


On Mon, Jul 30, 2018 at 9:33 PM Jeff LOMBARDO <jeff.lombardo at gmail.com>
wrote:

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

-- 
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/20180730/caf19ac1/attachment-0001.html>


More information about the Openid-specs-ab mailing list