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

Jeff LOMBARDO jeff.lombardo at gmail.com
Thu Aug 2 13:58:12 UTC 2018


Hi all,

Thanks Nat to follow-up. Sorry I did not take time to answer you earlier
Suresh.

Yes for Customers it applies too. Generally that's what happens with Social
OP.  So you should be able to enforce it for yours even if it is a private
OP.

Jeff

Le jeu. 2 août 2018 09:52, Nat Sakimura <sakimura at gmail.com> a écrit :

> Hi Suresh,
>
> Jeff's comment also applies to consumers. He was just citing an employee
> case but there is no difference for that matter.
>
> On Tue, Jul 31, 2018 at 4:42 AM SureshAtt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> 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
>> _______________________________________________
>> 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/20180802/05e77a4b/attachment-0001.html>


More information about the Openid-specs-ab mailing list