Subject: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 11 Mar 2019 15:05:40 -0700

Hi all,
during today's office hours call I pointed out that oauth-mtls-13's abstract
only mentions access token, although the spec does provide (some) guidance
on  refresh token binding as well.
Although in the end implementers would do the right thing, given that they
have to read the spec in its entirety, having a mention of refresh tokens
in the abstract as well would make it easier for superficial readers to
learn that the spec does address RTs as well. Refresh tokens leakage is one
of the top concerns of the customers I deal with, and those people rarely
read specs from cover to cover: having language in the abstract explicitly
calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy,

---

From: Brian Campbell <[email-masked]>
Date: Wed, 13 Mar 2019 17:20:32 -0600

As I kinda said on that call, I understand the ask and I do think it'd be
reasonable to mention refresh tokens in the abstract now that the document
does describe binding refresh tokens to the client certificate with public
clients.

I'm struggling to see the fix as pretty easy, however, given the text of
the abstract (copied below for ease of reference) and the content and scope
of the document.

Do you think changing the first sentence to have "certificate-bound access
and refresh tokens" is sufficient (and accurate)?

Or something more or different? In which case proposed text is always
welcome.

Abstract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.bertocci=
[email-masked]> wrote:

> on  refresh token binding as well..
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Filip Skokan <[email-masked]>
Date: Thu, 14 Mar 2019 08:07:50 +0100

Even before refresh tokens were mentioned in draft 13 i was about to
implement this binding in nodejs oidc-provider,

the thing i struggled with and ultimately didn't do this was

1) if the refresh token is bound to a specific cert then this cert rotation
is out of the question
2) if having the RT somehow covered is needed, isn't MTLS client auth
already the right thing to do? Especially given it supports cert rotation

Now the normative language is SHOULD therefore disallowing cert rotation.
Or am I missing something?

S pozdravem,
*Filip Skokan*

On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=
[email-masked]> wrote:

>> Although in the end implementers would do the right thing, given that
>> they have to read the spec in its entirety, having a mention of refresh
>> tokens in the abstract as well would make it easier for superficial readers
>> to learn that the spec does address RTs as well. Refresh tokens leakage is
>> one of the top concerns of the customers I deal with, and those people
>> rarely read specs from cover to cover: having language in the abstract
>> explicitly calling out RTs might make some conversations easier.
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Filip Skokan <[email-masked]>
Date: Thu, 14 Mar 2019 09:09:37 +0100

Point being that since the refresh token is only usable on the IdP then
mtls client auth already covers this, and since RTs are long-lasting, it
does this better because cert rotation is possible for both mtls methods.

S pozdravem,
*Filip Skokan*

On Thu, 14 Mar 2019 at 08:07, Filip Skokan <[email-masked]> wrote:

> 1) if the refresh token is bound to a specific cert then this cert
> rotation is out of the question
>> Do you think changing the first sentence to have "certificate-bound
>> access and refresh tokens" is sufficient (and accurate)?
>>

---

From: Neil Madden <[email-masked]>
Date: Thu, 14 Mar 2019 08:26:14 +0000

Right - this is what we have implemented. No support for certificate-bound refresh tokens, the client can be configured to require TLS cert client authentication instead. 

Neil

> On 14 Mar 2019, at 08:09, Filip Skokan <[email-masked]> wrote:
> 
> Point being that since the refresh token is only usable on the IdP then mtls client auth already covers this, and since RTs are long-lasting, it does this better because cert rotation is possible for both mtls methods.
> 
> S pozdravem,
> Filip Skokan
> 
> 
>> Even before refresh tokens were mentioned in draft 13 i was about to implement this binding in nodejs oidc-provider,
>> 
>> 1) if the refresh token is bound to a specific cert then this cert rotation is out of the question
>> 2) if having the RT somehow covered is needed, isn't MTLS client auth already the right thing to do? Especially given it supports cert rotation
>> 
>> Now the normative language is SHOULD therefore disallowing cert rotation. Or am I missing something?
>> 
>> S pozdravem,
>> Filip Skokan
>> 
>> 
>>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=[email-masked]> wrote:
>>> As I kinda said on that call, I understand the ask and I do think it'd be reasonable to mention refresh tokens in the abstract now that the document does describe binding refresh tokens to the client certificate with public clients. 
>>> 
>>> I'm struggling to see the fix as pretty easy, however, given the text of the abstract (copied below for ease of reference) and the content and scope of the document. 
>>> 
>>> Do you think changing the first sentence to have "certificate-bound access and refresh tokens" is sufficient (and accurate)? 
>>> 
>>> Or something more or different? In which case proposed text is always welcome.
>>> 
>>> Abstract
>>> 
>>>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.bertocci=[email-masked]> wrote:
>>>> Hi all,
>>>> during today's office hours call I pointed out that oauth-mtls-13's abstract only mentions access token, although the spec does provide (some) guidance on  refresh token binding as well.. 
>>>> Although in the end implementers would do the right thing, given that they have to read the spec in its entirety, having a mention of refresh tokens in the abstract as well would make it easier for superficial readers to learn that the spec does address RTs as well. Refresh tokens leakage is one of the top concerns of the customers I deal with, and those people rarely read specs from cover to cover: having language in the abstract explicitly calling out RTs might make some conversations easier.
>>>> 
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
>>> OAuth mailing list
>>> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Thu, 14 Mar 2019 06:28:42 -0600

Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound
to the client to whom it was issued. And that confidential clients (those
having established authn credentials) authenticate to the AS when
presenting a refresh token. Thus, for both MTLS methods of OAuth client
authentication, refresh tokens are indirectly certificate-bound through
their binding to a client and its credentials (and the client rotating its
cert doesn't invalidate the refresh token).

What was added in the -13 revision of the draft (in a new section
https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief
description of certificate binding refresh tokens for public clients.

The ask from Vittorio was a mention of refresh tokens in abstract. Which
seems reasonable. But the proper wording to succinctly and accurately
convey the aforementioned subtleties is proving difficult for me.

On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <[email-masked]>
wrote:

> Right - this is what we have implemented. No support for certificate-bound
> refresh tokens, the client can be configured to require TLS cert client
> authentication instead.
>
> Neil
>
> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <[email-masked]
> <[email-masked]>> wrote:
>
>>> As I kinda said on that call, I understand the ask and I do think it'd
>>> be reasonable to mention refresh tokens in the abstract now that the
>>> document does describe binding refresh tokens to the client certificate
>>> with public clients.
>>>
>>> review, use, distribution or disclosure by others is strictly
>>> prohibited...  If you have received this communication in error, please
>>> notify the sender immediately by e-mail and delete the message and any file
>>> attachments from your computer. Thank you.*

---

From: Filip Skokan <[email-masked]>
Date: Thu, 14 Mar 2019 13:53:21 +0100

Thank you for the clarification Brian, this makes sense.

So for clients not using mtls (or is this only clients using "none"?) to
authenticate the tls_client_certificate_bound_access_tokens client metadata
property also conditions binding the refresh token. At the cost of the RT
being unusable if the client loses or rotates the certificate.

Best,
*Filip*

On Thu, 14 Mar 2019 at 13:29, Brian Campbell <[email-masked]>
wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a
> brief description of certificate binding refresh tokens for public clients.
>
>> Right - this is what we have implemented. No support for
>> certificate-bound refresh tokens, the client can be configured to require
>> TLS cert client authentication instead.
>>
>> Neil
>>
>>>> I'm struggling to see the fix as pretty easy, however, given the text
>>>> of the abstract (copied below for ease of reference) and the content and
>>>> scope of the document.
>>>>
> review, use, distribution or disclosure by others is strictly prohibited.
> your computer. Thank you.*

---

From: Neil Madden <[email-masked]>
Date: Thu, 14 Mar 2019 13:13:56 +0000

It’s not clear to me how this works or what problem it is solving. If a refresh token is bound to the certificate, does that mean that a call to the introspection endpoint with that refresh token should also return a “cnf” claim as per https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ? 

It also seems problematic to implement this for refresh tokens. As mentioned by Filip, rotation of the certificate is out of the question. Currently in our implementation a client could present a new certificate when using the refresh token and this would result in the newly issued access token being bound to the new certificate. If the refresh token is bound to the original certificate, then this would be ruled out (the new certificate would be rejected) and certificate rotation becomes impossible in all cases. Am I missing something?

— Neil

> On 14 Mar 2019, at 12:28, Brian Campbell <[email-masked]> wrote:
> 
> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound to the client to whom it was issued. And that confidential clients (those having established authn credentials) authenticate to the AS when presenting a refresh token. Thus, for both MTLS methods of OAuth client authentication, refresh tokens are indirectly certificate-bound through their binding to a client and its credentials (and the client rotating its cert doesn't invalidate the refresh token).
> 
> What was added in the -13 revision of the draft (in a new section https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief description of certificate binding refresh tokens for public clients.
> 
> The ask from Vittorio was a mention of refresh tokens in abstract. Which seems reasonable. But the proper wording to succinctly and accurately convey the aforementioned subtleties is proving difficult for me.
> 
> 
> 
> 
> 
> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <[email-masked]> wrote:
>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <[email-masked]> wrote:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 14 Mar 2019 07:57:08 -0600

Yeah Filip, that's about right. Currently the text says to do it only for
public clients (clients using "none").

On Thu, Mar 14, 2019 at 6:53 AM Filip Skokan <[email-masked]> wrote:

>> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be
>> bound to the client to whom it was issued. And that confidential clients
>> (those having established authn credentials) authenticate to the AS when

---

From: Brian Campbell <[email-masked]>
Date: Thu, 14 Mar 2019 12:50:00 -0600

Certificate-binding refresh tokens issued to *public clients* (those that
don't have authentication credentials established with the AS, a.k.a.
clients configured or registered with the "none" authentication method,
which will typically be native apps on a phone or similar) adds protections
against malicious use or reuse of those refresh tokens where no protections
would otherwise exist. It's true that certificate rotation in that
situation would invalidate the refresh token. But not being able to rotate
a strong asymmetric credential without invaliding the refresh token seems a
very reasonable trade off vs. not having a credential bound to the token at
all.

I guess I would say that what is returned when introspecting such a refresh
token is an implementation detail that is at the discretion of said
implementation. That seems consistent with the level of guidance in
introspection for refresh tokens currently. And there's not really an
interoperability angle that I can see. So that seems fine. Also, some form
of authorization is required to access the introspection endpoint so I'm
not sure how a refresh token issued to a public client would realistically
get introspected. I guess, if I'm being honest, I don't really get refresh
token introspection in general so probably better that I stop opining on
the subject.

On Thu, Mar 14, 2019 at 7:13 AM Neil Madden <[email-masked]>
wrote:

> It’s not clear to me how this works or what problem it is solving. If a
> refresh token is bound to the certificate, does that mean that a call to
> the introspection endpoint with that refresh token should also return a
> “cnf” claim as per
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ?
>
> It also seems problematic to implement this for refresh tokens. As
> mentioned by Filip, rotation of the certificate is out of the question.
> Currently in our implementation a client could present a new certificate
> when using the refresh token and this would result in the newly issued
> access token being bound to the new certificate. If the refresh token is
> bound to the original certificate, then this would be ruled out (the new
> certificate would be rejected) and certificate rotation becomes impossible
> in all cases. Am I missing something?
>
> — Neil
>
> >> during today's office hours call I pointed out that oauth-mtls-13's
> abstract only mentions access token, although the spec does provide (some)
> guidance on  refresh token binding as well..
> >> CONFIDENTIALITY NOTICE: This email may contain confidential and
> attachments from your computer. Thank
> you._______________________________________________
> >> OAuth mailing list
> >> [email-masked]
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> your computer. Thank you.
>
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 14 Mar 2019 15:13:46 -0400

The one use case I've run across for introspecting refresh_tokens is to 
determine the lifetime of the refresh_token (i.e. when it expires). Some 
authorization servers bind the refresh_token to the user's 
authentication session and hence they have a defined lifetime. I suppose 
another use case might be to determine all the scopes that were issued 
to the refresh_token. That of course should require the correct 
authorization at the introspection endpoint in order to obtain the scope 
data:)

On 3/14/19 2:50 PM, Brian Campbell wrote:
> Certificate-binding refresh tokens issued to *public clients* (those 
> that don't have authentication credentials established with the AS, 
> a.k.a. clients configured or registered with the "none" authentication 
> method, which will typically be native apps on a phone or similar) 
> adds protections against malicious use or reuse of those refresh 
> tokens where no protections would otherwise exist. It's true that 
> certificate rotation in that situation would invalidate the refresh 
> token. But not being able to rotate a strong asymmetric credential 
> without invaliding the refresh token seems a very reasonable trade off 
> vs. not having a credential bound to the token at all.
>
> I guess I would say that what is returned when introspecting such a 
> refresh token is an implementation detail that is at the discretion of 
> said implementation. That seems consistent with the level of guidance 
> in introspection for refresh tokens currently. And there's not really 
> an interoperability angle that I can see. So that seems fine. Also, 
> some form of authorization is required to access the introspection 
> endpoint so I'm not sure how a refresh token issued to a public client 
> would realistically get introspected. I guess, if I'm being honest, I 
> don't really get refresh token introspection in general so probably 
> better that I stop opining on the subject.
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 7:13 AM Neil Madden <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     It’s not clear to me how this works or what problem it is solving.
>     If a refresh token is bound to the certificate, does that mean
>     that a call to the introspection endpoint with that refresh token
>     should also return a “cnf” claim as per
>     https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2
>     <https://tools.ietf..org/html/draft-ietf-oauth-mtls-13#section-3.2> ?
>
>     mentioned by Filip, rotation of the certificate is out of the
>     question. Currently in our implementation a client could present a
>     new certificate when using the refresh token and this would result
>     in the newly issued access token being bound to the new
>     certificate. If the refresh token is bound to the original
>     certificate, then this would be ruled out (the new certificate
>     would be rejected) and certificate rotation becomes impossible in
>     all cases. Am I missing something?
>
>     — Neil
>
>     > On 14 Mar 2019, at 12:28, Brian Campbell
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >
>     > Yeah, so regular old RFC 6749 OAuth requires that a refresh
>     token be bound to the client to whom it was issued. And that
>     confidential clients (those having established authn credentials)
>     authenticate to the AS when presenting a refresh token. Thus, for
>     both MTLS methods of OAuth client authentication, refresh tokens
>     are indirectly certificate-bound through their binding to a client
>     and its credentials (and the client rotating its cert doesn't
>     invalidate the refresh token).
>     >
>     https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4)
>     was a brief description of certificate binding refresh tokens for
>     public clients.
>     >
>     > The ask from Vittorio was a mention of refresh tokens in
>     abstract. Which seems reasonable. But the proper wording to
>     succinctly and accurately convey the aforementioned subtleties is
>     proving difficult for me.
>     >
>     >
>     >
>     >
>     >
>     > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     certificate-bound refresh tokens, the client can be configured to
>     require TLS cert client authentication instead.
>     >
>     > Neil
>     >
>     > On 14 Mar 2019, at 08:09, Filip Skokan <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     >> Point being that since the refresh token is only usable on the
>     IdP then mtls client auth already covers this, and since RTs are
>     long-lasting, it does this better because cert rotation is
>     possible for both mtls methods.
>     >>
>     >> S pozdravem,
>     >> Filip Skokan
>     >>
>     >>
>     <mailto:[email-masked]>> wrote:
>     >> Even before refresh tokens were mentioned in draft 13 i was
>     about to implement this binding in nodejs oidc-provider,
>     >>
>     >> 2) if having the RT somehow covered is needed, isn't MTLS
>     client auth already the right thing to do? Especially given it
>     supports cert rotation
>     >>
>     >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell
>     <bcampbell=[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> As I kinda said on that call, I understand the ask and I do
>     think it'd be reasonable to mention refresh tokens in the abstract
>     now that the document does describe binding refresh tokens to the
>     client certificate with public clients.
>     >>
>     >> I'm struggling to see the fix as pretty easy, however, given
>     the text of the abstract (copied below for ease of reference) and
>     the content and scope of the document.
>     >>
>     >> Do you think changing the first sentence to have
>     "certificate-bound access and refresh tokens" is sufficient (and
>     accurate)?
>     >>
>     >> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci
>     <vittorio.bertocci=[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> Hi all,
>     >> during today's office hours call I pointed out that
>     oauth-mtls-13's abstract only mentions access token, although the
>     spec does provide (some) guidance on  refresh token binding as well..
>     >> Although in the end implementers would do the right thing,
>     given that they have to read the spec in its entirety, having a
>     mention of refresh tokens in the abstract as well would make it
>     easier for superficial readers to learn that the spec does address
>     RTs as well. Refresh tokens leakage is one of the top concerns of
>     the customers I deal with, and those people rarely read specs from
>     cover to cover: having language in the abstract explicitly calling
>     out RTs might make some conversations easier.
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     privileged material for the sole use of the intended recipient(s).
>     Any review, use, distribution or disclosure by others is strictly
>     prohibited...  If you have received this communication in error,
>     please notify the sender immediately by e-mail and delete the
>     message and any file attachments from your computer. Thank
>     >> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     privileged material for the sole use of the intended recipient(s).
>     Any review, use, distribution or disclosure by others is strictly
>     prohibited.  If you have received this communication in error,
>     please notify the sender immediately by e-mail and delete the
>     message and any file attachments from your computer. Thank you.
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> prohibited..  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 14 Mar 2019 19:49:48 +0000

Comments in-line:

> On 14 Mar 2019, at 18:50, Brian Campbell <[email-masked]> wrote:
> 
> Certificate-binding refresh tokens issued to *public clients* (those that don't have authentication credentials established with the AS, a.k.a. clients configured or registered with the "none" authentication method, which will typically be native apps on a phone or similar) adds protections against malicious use or reuse of those refresh tokens where no protections would otherwise exist.

Refresh tokens have a different threat model to access tokens as they are only communicated directly between the client and the AS over a secure channel. The main risk is of them being compromised on the client [*], but then a private key is at the same risk. Even if you generate the private key in a TPM on the device (eg mobile device with secure hardware), any malicious actor that is able to extract the refresh token from the client is also presumably in a position to either proxy requests through an existing TLS connection on that client or else interact with the TPM to create a new one. 

[*] Or by a compromise of TLS, but that breaks everything. 

> It's true that certificate rotation in that situation would invalidate the refresh token. But not being able to rotate a strong asymmetric credential without invaliding the refresh token seems a very reasonable trade off vs. not having a credential bound to the token at all. 

I would not make that trade-off. If you are at OSW next week, I am presenting some cases for OAuth mTLS in a kubernetes environment that have public clients with long-lived grants that use refresh tokens to periodically rotate certs. 

> I guess I would say that what is returned when introspecting such a refresh token is an implementation detail that is at the discretion of said implementation. That seems consistent with the level of guidance in introspection for refresh tokens currently. And there's not really an interoperability angle that I can see. So that seems fine. Also, some form of authorization is required to access the introspection endpoint so I'm not sure how a refresh token issued to a public client would realistically get introspected. I guess, if I'm being honest, I don't really get refresh token introspection in general so probably better that I stop opining on the subject. 

Ok, I’m happy to just ignore that aspect for refresh tokens then. 

— Neil

> 
> 
> 
> 
> 
> 
>> On Thu, Mar 14, 2019 at 7:13 AM Neil Madden <[email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Fri, 15 Mar 2019 14:55:34 -0600

Your point about refresh tokens having a different threat model to access
tokens is taken, however, I think I'd stop short of saying a private key is
always at the same risk.

I will be at OSW next week and look forward to your presentation. Hopefully
it'll help me better understand the threat model and goals and constraints
and etc. you are working with.

As far as the document is concerned, there are folks that are interested in
the cert-binding of refresh tokens for public clients. So I don't it should
be removed. The text in -13 has a SHOULD for it so your case of not
cert-binding RTs is still within the lines of the spec. But perhaps that
SHOULD can be loosened and/or qualified somewhat so as to better
accommodate that case. I was trying to avoid it, but introducing a client
metadata flag to toggle the RT binding behavior is also a potential option.

On Thu, Mar 14, 2019 at 1:49 PM Neil Madden <[email-masked]>
wrote:

> would otherwise exist.
> Refresh tokens have a different threat model to access tokens as they are
> only communicated directly between the client and the AS over a secure
> channel. The main risk is of them being compromised on the client [*], but
> then a private key is at the same risk. Even if you generate the private
> key in a TPM on the device (eg mobile device with secure hardware), any
> malicious actor that is able to extract the refresh token from the client
> is also presumably in a position to either proxy requests through an
> existing TLS connection on that client or else interact with the TPM to
> create a new one.
>
> It's true that certificate rotation in that situation would invalidate the
> refresh token. But not being able to rotate a strong asymmetric credential
> without invaliding the refresh token seems a very reasonable trade off vs.
> not having a credential bound to the token at all.
>
>
> I would not make that trade-off. If you are at OSW next week, I am
> presenting some cases for OAuth mTLS in a kubernetes environment that have
> public clients with long-lived grants that use refresh tokens to
> periodically rotate certs.
>
> refresh token is an implementation detail that is at the discretion of said
>> > The ask from Vittorio was a mention of refresh tokens in abstract.
>> Which seems reasonable. But the proper wording to succinctly and accurately
>> >> Point being that since the refresh token is only usable on the IdP
>> then mtls client auth already covers this, and since RTs are long-lasting,
>> it does this better because cert rotation is possible for both mtls methods.
>> >>
>> >> S pozdravem,
>> >> Filip Skokan
>> >>
>> >>