Hi Jaimandeep,
I disagree with both of your points. See my comments inline.
Best regards,
Karsten
On 12.08.2022 05:40, Jaimandeep Singh wrote:
Hi Mikheil,
1. Well explained by Brain. I will just add my perspective.
>From the practical perspective, if the confidential client got a
refresh
token for the offline access and sufficient time (e.g., for a
month), this
would be quite impractical and not very user-friendly to ask a lot
of users
to give consents again when the confidential client wants to
upgrade its
certificate. But seems like software vendors did not interpret the
RFC that
way.
For confidential clients, authorization code flow is recommended. It
is a two step process. In the first step you get the authorization
code when the user provides his/her consent. In the second step you
use this authorization code along with client credentials to obtain
access tokens and refresh tokens. If the refresh token expires either
due to expiry of its lifetime or certificate, it only needs to follow
step two. So, the question of asking for consent again does not arise
unless the authorization code itself has limited lifespan.
IMHO authorization codes should always be implemented as one-time-use
tokens. Even when there is a grace period allowing a client to redeem a
code a second time (e.g., in case of network failure) this period should
be very short - much shorter than the validity of refresh tokens in
practice.
If the refresh token is expired, the client should start a new
authorization flow and ask the user for consent again unless the AS
provides a way for users to grant access for clients "permanently".
2.
While RFC 8705 indeed requires binding refresh token to the
certificate in
case of the public clients in Section 4 and Section 7.1
The RFC 8705 talks about public clients and refresh tokens in the same
breath and seems to have legitimized the use of refresh tokens for
public clients. However, if we look at the original OAuth 2.0
specifications RFC 6749, Section 4.2, talks about implicit grant
optimized for public clients. It does not support issuing refresh
tokens by AS in the first place. I think there is a need to
deliberate on this issue in the next update / errata for RFC 8705.
RFC 6749 is much older than RFC 8705. Both drafts "OAuth 2.0 Security
Best Current Practice" (hopefully soon to be finished) and OAuth 2.1
deprecate issuing access tokens from the authorization endpoint (which
is more or less the implicit grant). Today's best practice is to use the
authorization code grant for both confidential and public clients.
Therefore, I do not think there is a need for an updated RFC replacing 8705.
Regards and Best Wishes
Jaimandeep Singh
On Thu, Aug 11, 2022 at 11:46 PM <mikh...@association.ge> wrote:
Hi Brian,
Thanks for the prompt response. We will work with our vendors to
get this done according to the RFC.
Best Regards,
Mikheil Kapanadze
From: Brian Campbell <bcampb...@pingidentity.com>
Sent: ხუთშაბათი, 11 აგვისტო, 2022 21:04
To: mikh...@association.ge
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Certificate-bound refresh tokens and
certificate expiration handling in case of the confidential clients
Hi Mikheil,
Your assumption is the correct reading of the RFC. Or the intent
of the RFC anyway. For confidential clients, refresh tokens are
bound to the client id (not the certificate thumbprint or anything
else for that matter).
RFCs can't be changed after publication so adding more
clarification isn't really possible.
On Thu, Aug 11, 2022 at 9:11 AM <mailto:mikh...@association.ge> wrote:
Hi,
I have noticed is that some OAuth2 AS implementations use certificate
thumbprints to bind not only access tokens but also refresh tokens
to client
certificates. This happens for both public and confidential
clients. As a
result, when the certificate is replaced (e.g., it is about to
expire soon),
both access and refresh tokens are drawn unusable.
While RFC 8705 indeed requires binding refresh token to the
certificate in
case of the public clients in Section 4 and Section 7.1, the
wording is not
that explicit for the confidential clients. More specifically,
Section 7.1
of the RFC 8705 is worded in a way which does not explicitly deny
keeping
refresh tokens alive after certificate change: it talks about
binding to
client ID, thus binding "indirectly" to the certificate. Also,
Section 6.3
requires access tokens to be invalidated after certificate change and
mentions refresh tokens as typical tools for renewing them.
>From the practical perspective, if the confidential client got a
refresh
token for the offline access and sufficient time (e.g., for a
month), this
would be quite impractical and not very user-friendly to ask a lot
of users
to give consents again when the confidential client wants to
upgrade its
certificate. But seems like software vendors did not interpret the
RFC that
way.
So, the questions:
1) Is my assumption correct and it will not be a violation of the
RFC if
refresh tokens issued to the confidential clients survive
certificate change
(e.g., by binding them to Client ID, not the certificate thumbprint)?
2) If the answer on the 1st question is “yes”, would it be better
to provide
more clarification in the section 7.1 to avoid misinterpretations
in the
future?
Best Regards,
Mikheil Kapanadze
_______________________________________________
OAuth mailing list
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
https://www.ietf.org/mailman/listinfo/oauth
--
Regards and Best Wishes
Jaimandeep Singh
LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone: +49 (0)234 / 54456499
Web: https://hackmanit.de | IT Security Consulting, Penetration Testing,
Security Training
Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? Find
out more on our blog:
https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum
Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr.
Christian Mainka, Prof. Dr. Marcus Niemietz
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
