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 <neil.mad...@forgerock.com
<mailto:neil.mad...@forgerock.com>> 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> ?
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
<bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>>
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
<neil.mad...@forgerock.com <mailto:neil..mad...@forgerock.com>> 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 14 Mar 2019, at 08:09, Filip Skokan <panva...@gmail.com
<mailto:panva...@gmail.com>> 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
>>
>>
>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva....@gmail.com
<mailto:panva....@gmail.com>> wrote:
>> 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=40pingidentity....@dmarc.ietf.org
<mailto:40pingidentity....@dmarc.ietf.org>> 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
>>
>> 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=40auth0....@dmarc.ietf.org
<mailto:40auth0....@dmarc.ietf.org>> 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.
>>
>> This is admittedly very minor, but the fix would also be pretty
easy,
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> 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._______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> 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.
/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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
