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

SureshAtt suresh.attanayake at gmail.com
Sat Aug 4 22:22:38 UTC 2018


Hello Jeff, really sorry for the typo in the name.

On Sun, Aug 5, 2018 at 12:21 AM SureshAtt <suresh.attanayake at gmail.com>
wrote:

> Hello Jett and Nat,
>
> Thank you very much for your replies. However I’m quite not sure how I can
> apply the proposed solutions in this case. Maybe I should elaborate the
> scenario:
>
> use case:
>
>    1. User visit the web application first time => trigger an OIDC flow
>    and authenticate the user to the application.
>    2. User bookmarks a page in the application.
>    3. User visits the application again later (few days maybe) using the
>    bookmark => User is automatically signed in (without the redirect to OP)
>
> restrictions:
>
>    1. Application is a web application of type SPA.
>    2. Applications is hosted in a different network than the OP is or any
>    other application is.
>    3. Application is required to have a valid access token to consume
>    external APIs for its functionalities.
>    4. OP is supporting only the standard grant types.
>    5. OP doesn’t provide any other endpoints/protocols for user
>    authentication other than OIDC.
>    6. Users of the applications are customers coming from internet using
>    their personal devices which can be of any type.
>
> I think above restrictions are not that uncommon for SPAs using OIDC for
> user authentication. And due to above restrictions I am not sure if the
> proposed solutions (Kerberos/IWA) can be used in this case, or is there any
> other alternative?
>
> If restriction #1 was not there, then the use case can be easily covered
> with a server backend using the code flow and a remember me cookie
>
>    1. Sign in user using OIDC if remember me cookie is not present. Store
>    the resulting refresh token in server side.
>    2. When user visit next time, detect and validate the remember me
>    cookie and then refresh the access token.
>
>
>    - Access token can have a shorter lifetime to cover the server session
>       lifetime (30 mins). The token refresh can be used detect if user still
>       exists in the system and also to enforce revocation of user consent.
>
> But in the case of a SPA, getting new access token without a browser
> redirect is the challenge. This is why I read the specification again for
> the hybrid flow to understand if it handles a similar use case and then I
> ended up with those questions I asked in my initial email. But after your
> clarification about the hybrid flow, for me it’s clear that it is not
> possible for a SPA to get a new access token without a browser redirect.
>
> I think the use case is still valid, however it seems a SPA cannot cover
> this use case with above restrictions with OIDC. Or do you think otherwise?
>
> Thanks & regards,
> Suresh Attanayake
>
> On Thu, Aug 2, 2018 at 3:58 PM Jeff LOMBARDO <jeff.lombardo at gmail.com>
> wrote:
>
>> 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
>>>
>>
>
> --
> 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
>


-- 
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/20180805/4f749529/attachment-0001.html>


More information about the Openid-specs-ab mailing list