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 mode
Comments in-line:
> On 14 Mar 2019, at 18:50, 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, wh
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 m
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
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 wrote:
> Thank you for the clarification Brian, this makes sense.
>
> So for clients not using mtls (or is this only clients using "none"?
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
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
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
authenticati
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 wrote:
>
> Point being that since the refresh token is only usable on the I
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 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
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
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
13 matches
Mail list logo
