Subject: [OAUTH-WG] proof of access token possession using client secret

From: Nikos Fotiou <[email-masked]>
Date: Wed, 2 Mar 2022 17:58:17 +0200

Hi all,

I am working on a use case where the Authorization Server and the Resource Server are the same entity. I would like to prevent clients from sharing their access tokens. I am wondering if requiring clients to include the "client secret" in the resource access request (in addition to the access token) is a valid strategy. This way clients would have to share their "client secret" in addition to the access token. Would that work?

Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

---

From: Warren Parad <[email-masked]>
Date: Wed, 2 Mar 2022 17:18:38 +0100

Is there a reason you wouldn't want to use the access token to access these
resources? That seems like it would be the optimal strategy.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Wed, Mar 2, 2022 at 4:58 PM Nikos Fotiou <[email-masked]> wrote:

> Hi all,
>
> I am working on a use case where the Authorization Server and the Resource
> Server are the same entity. I would like to prevent clients from sharing
> their access tokens. I am wondering if requiring clients to include the
> "client secret" in the resource access request (in addition to the access
> token) is a valid strategy. This way clients would have to share their
> "client secret" in addition to the access token. Would that work?
>
> Best,
> Nikos
> --
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Jim Manico <[email-masked]>
Date: Wed, 2 Mar 2022 08:22:37 -0800

> I would like to prevent clients from sharing their access tokens. I 
am wondering if requiring clients to include the "client secret" in the 
resource access request (in addition to the access token) is a valid 
strategy.

Sender-constrained access tokens are suggested in the current security 
best practice guide here. 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-2.2

So yes!

- Jim Manico

On 3/2/22 8:18 AM, Warren Parad wrote:
> Is there a reason you wouldn't want to use the access token to access 
> these resources? That seems like it would be the optimal strategy.
>
> 	
>
> Warren Parad
>
> Founder, CTO
>
>     I am working on a use case where the Authorization Server and the
>     Resource Server are the same entity. I would like to prevent
>     clients from sharing their access tokens. I am wondering if
>     requiring clients to include the "client secret" in the resource
>     access request (in addition to the access token) is a valid
>     strategy. This way clients would have to share their "client
>     secret" in addition to the access token. Would that work?
>
>     Best,
>     Nikos
>     --

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: George Fletcher <[email-masked]>
Date: Wed, 2 Mar 2022 11:44:39 -0500

You could require client authentication via the allowed OAuth mechanisms 
on all resource requests. I think there is some danger in sending the 
client_secret across the wire on all requests even if the endpoints are 
all part of the same service. I'd recommend looking at DPoP [1].

Thanks,
George

[1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-06

On 3/2/22 11:22 AM, Jim Manico wrote:
> am wondering if requiring clients to include the "client secret" in 
> the resource access request (in addition to the access token) is a 
> valid strategy.
>

---

From: Daniel Fett <[email-masked]>
Date: Wed, 2 Mar 2022 18:18:55 +0100

What exactly is the attack that you're trying to prevent?

If the clients share the access tokens, they might as well share access 
to the resource server (forwarding requests and responses). You can't 
really prevent that.

DPoP or MTLS, potentially with non-exportable keys, might be a better 
approach, but it depends on the attack you have in mind.

-Daniel

Am 02.03.22 um 16:58 schrieb Nikos Fotiou:
> Nikos Fotiou -http://pages.cs.aueb.gr/~fotiou

-- 
https://danielfett.de

---

From: Denis <[email-masked]>
Date: Wed, 2 Mar 2022 18:37:47 +0100

Nikos,

You wrote:

     I would like to prevent clients from sharing their access tokens.

Proof of access token possession using client secret is unable to 
prevent clients from sharing their access tokens.

When two clients agree to collaborate, one client can perform all the 
cryptographic computations that the  other client
needs (without the need to release the private key to the other client).

At the last OAuth security workshop, I have presented a solution. 
Hereafter is an extract of the abstract;

     Access tokens that contain a binding user-identifier (buid) field 
provide a protection against collusions between two collaborative clients
     that key-bound access tokens are unable to provide.

     The use of a binding user-identifier (buid) field allows a client 
to choose between different contexts and between different privacy 
properties.

     More details are present in 
https://www.ietf.org/id/draft-pinkas-gnap-core-protocol-00.txt

Daniel,

You wrote:

    If the clients share the access tokens, they might as well share
    access to the resource server (forwarding requests and responses).
    You can't really prevent that.

When you consider the existence of user accounts and in the context of 
some practical cases, you can prevent that.

> If the clients share the access tokens, they might as well share 
> access to the resource server (forwarding requests and responses). You 
> can't really prevent that.
>