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

[Nat Sakimura]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180729/5085afc7/attachment.html>