Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

[Aaron Parecki]

The consent is typically associated with the user and client_id pair, the
authorization code is just a temporary artifact used for the client to
obtain a token regardless of consent.

Whether a client_id is used for a large number of instances of a client is
up to a particular deployment and is not always true or false.

Plus there's the issue of public clients mentioned in RFC6749, suggesting
that public clients should not bypass the consent screen even if the user
has already approved a particular client.

Basically what you're asking about is already possible and already done by
many systems, I'm not sure there is anything that needs to be done in terms
of the specification to enable what you're suggesting.

Aaron



On Wed, Aug 24, 2022 at 11:01 AM Jaimandeep Singh <
jaimandeep.phdc...@nfsu.ac.in> wrote:

> Hi Torsten,
> 1. You are right that consent can be preserved at the AS. The concern here
> is what happens when the refresh token expires? Do we again go back to the
> user and ask for consent or is there some way for the AS to bind the client
> with the consent that has already been given? As I understand, the AS does
> this binding by way of tuple (client_id, authorization code). If we remove
> the authorization code from this tuple there is no way for the AS to know
> that authorization was given to which client, as client_id is common for a
> large number of instances of the same client application.
>
> 2. As we discuss, the WG may also consider including an additional claim
> called "duration_of_consent". The user while giving the consent can have
> the option to choose the duration for which the consent has been given.
> This will be in line with the privacy requirements all over the world.
> Also, it will give a definite time period after which the consent
> automatically expires. It will also improve the overall security of the
> protocol.
>
> Kind Regards
> Jaimandeep Singh
>
>
> On Wed, Aug 24, 2022 at 8:23 PM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> the consent is not bound to the code. As you correctly pointed out, the
>> code is a temporary artifact. It’s purpose is to bridge insecure
>> frontchannel communication to more secure backchannel communication. You
>> don’t need to preserve the code in order to preserve the consent. The code
>> is merely intended to be a reference to the consent (or grant). So even if
>> the code expires, the consent can be preserved and updated in the AS. In
>> the simplest case, it is transferred to the refresh token. In more
>> sophisticated implementations, the consent is a first class object in the
>> AS.
>>
>> best regards,
>> Torsten.
>>
>> Am 19.08.2022 um 16:23 schrieb Jaimandeep Singh <
>> jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org>:
>>
>> Hi Karsten,
>>
>> Thx a lot for all the time and effort in explaining the things. This
>> brings up an important discussion point as we are revising OAuth 2.0. Do we
>> need to make the authorization code a temporary token? Section 1.3.1 of the
>> draft RFC states:
>>
>>> An authorization code is a temporary credential used to obtain an access
>>> token.
>>
>> Here, I am only considering the case of human interaction where it is
>> necessary to take the consent of the human (resource owner) before granting
>> access to his protected resources. As I have already mentioned in the trail
>> mail, OAuth is a two step process: Step 1: Take consent from the user. Step
>> 2: Handover that consent to the third party to access resources on the
>> user's behalf.
>>
>> Now, if we make authorization code a temporary artifact, we will never be
>> able to go back to the previous step and will have to per-force start the
>> process again. Now, with RFC 8705 client applications can be identified
>> with the private key, which are also of rotating nature. We also have DPoP
>> and certificate thumbprints coming up. Then, how wise it is to discard this
>> important token and start all over again.
>>
>> So, my recommendation is not to make the authorization code temporary
>> especially when used with DPoP and thumbprint cnf. This will reduce the
>> headache of asking the consent from a human user because the refresh token
>> expired.
>>
>> For kind consideration of the members please.
>>
>> Regards and Best Wishes
>> Jaimandeep Singh
>>
>> On Fri, Aug 19, 2022 at 7:07 PM Karsten Meyer zu Selhausen <
>> karsten.meyerzuselhau...@hackmanit.de> wrote:
>>
>>> 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 

Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

[Jaimandeep Singh]

Hi Torsten,
1. You are right that consent can be preserved at the AS. The concern here
is what happens when the refresh token expires? Do we again go back to the
user and ask for consent or is there some way for the AS to bind the client
with the consent that has already been given? As I understand, the AS does
this binding by way of tuple (client_id, authorization code). If we remove
the authorization code from this tuple there is no way for the AS to know
that authorization was given to which client, as client_id is common for a
large number of instances of the same client application.

2. As we discuss, the WG may also consider including an additional claim
called "duration_of_consent". The user while giving the consent can have
the option to choose the duration for which the consent has been given.
This will be in line with the privacy requirements all over the world.
Also, it will give a definite time period after which the consent
automatically expires. It will also improve the overall security of the
protocol.

Kind Regards
Jaimandeep Singh


On Wed, Aug 24, 2022 at 8:23 PM Torsten Lodderstedt  wrote:

> Hi,
>
> the consent is not bound to the code. As you correctly pointed out, the
> code is a temporary artifact. It’s purpose is to bridge insecure
> frontchannel communication to more secure backchannel communication. You
> don’t need to preserve the code in order to preserve the consent. The code
> is merely intended to be a reference to the consent (or grant). So even if
> the code expires, the consent can be preserved and updated in the AS. In
> the simplest case, it is transferred to the refresh token. In more
> sophisticated implementations, the consent is a first class object in the
> AS.
>
> best regards,
> Torsten.
>
> Am 19.08.2022 um 16:23 schrieb Jaimandeep Singh <
> jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org>:
>
> Hi Karsten,
>
> Thx a lot for all the time and effort in explaining the things. This
> brings up an important discussion point as we are revising OAuth 2.0. Do we
> need to make the authorization code a temporary token? Section 1.3.1 of the
> draft RFC states:
>
>> An authorization code is a temporary credential used to obtain an access
>> token.
>
> Here, I am only considering the case of human interaction where it is
> necessary to take the consent of the human (resource owner) before granting
> access to his protected resources. As I have already mentioned in the trail
> mail, OAuth is a two step process: Step 1: Take consent from the user. Step
> 2: Handover that consent to the third party to access resources on the
> user's behalf.
>
> Now, if we make authorization code a temporary artifact, we will never be
> able to go back to the previous step and will have to per-force start the
> process again. Now, with RFC 8705 client applications can be identified
> with the private key, which are also of rotating nature. We also have DPoP
> and certificate thumbprints coming up. Then, how wise it is to discard this
> important token and start all over again.
>
> So, my recommendation is not to make the authorization code temporary
> especially when used with DPoP and thumbprint cnf. This will reduce the
> headache of asking the consent from a human user because the refresh token
> expired.
>
> For kind consideration of the members please.
>
> Regards and Best Wishes
> Jaimandeep Singh
>
> On Fri, Aug 19, 2022 at 7:07 PM Karsten Meyer zu Selhausen <
> karsten.meyerzuselhau...@hackmanit.de> wrote:
>
>> 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 

Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

[Torsten Lodderstedt]

Hi, 

the consent is not bound to the code. As you correctly pointed out, the code is 
a temporary artifact. It’s purpose is to bridge insecure frontchannel 
communication to more secure backchannel communication. You don’t need to 
preserve the code in order to preserve the consent. The code is merely intended 
to be a reference to the consent (or grant). So even if the code expires, the 
consent can be preserved and updated in the AS. In the simplest case, it is 
transferred to the refresh token. In more sophisticated implementations, the 
consent is a first class object in the AS. 

best regards,
Torsten.  

> Am 19.08.2022 um 16:23 schrieb Jaimandeep Singh 
> :
> 
> Hi Karsten,
> 
> Thx a lot for all the time and effort in explaining the things. This brings 
> up an important discussion point as we are revising OAuth 2.0. Do we need to 
> make the authorization code a temporary token? Section 1.3.1 of the draft RFC 
> states:
> An authorization code is a temporary credential used to obtain an access 
> token. 
> Here, I am only considering the case of human interaction where it is 
> necessary to take the consent of the human (resource owner) before granting 
> access to his protected resources. As I have already mentioned in the trail 
> mail, OAuth is a two step process: Step 1: Take consent from the user. Step 
> 2: Handover that consent to the third party to access resources on the user's 
> behalf. 
> 
> Now, if we make authorization code a temporary artifact, we will never be 
> able to go back to the previous step and will have to per-force start the 
> process again. Now, with RFC 8705 client applications can be identified with 
> the private key, which are also of rotating nature. We also have DPoP and 
> certificate thumbprints coming up. Then, how wise it is to discard this 
> important token and start all over again.
> 
> So, my recommendation is not to make the authorization code temporary 
> especially when used with DPoP and thumbprint cnf. This will reduce the 
> headache of asking the consent from a human user because the refresh token 
> expired.
> 
> For kind consideration of the members please.
> 
> Regards and Best Wishes
> Jaimandeep Singh 
> 
> On Fri, Aug 19, 2022 at 7:07 PM Karsten Meyer zu Selhausen 
>  > wrote:
> 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