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

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 com

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

> > I like the idea of a machine-readable feature support document... > discovering those documents might still be a problem, though. Yay! I don't think it is hard to build a bot to iterate github/github and pull these. It gives us a starting point for how to attack this problem. The key compone

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

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 a

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

Hi Warren, Am 02.03.22 um 17:05 schrieb Warren Parad: I don't think flooding this thread with random libraries is going to benefit anyone, so let's not do that. I agree, and that was not the aim of my question. Back to the question, and it is an interesting one. It makes sense to dissect

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

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

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

Hi Daniel I do think it’s a problem that’s worth addressing somehow. I think there’s another factor, which is that the providers of OAuth2 Authorization Servers (where they don’t have their own SDKs specific to their server) tend to lead the developer through how to do a “from scratch” impleme

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

> 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 b

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

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 . On Wed, Mar 2, 2022 at 4:58 PM

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

I don't think flooding this thread with random libraries is going to benefit anyone, so let's not do that. Back to the question, and it is an interesting one. It makes sense to dissect it a bit first. Who is struggling with "OAuth libraries" and what is even the responsibility of one of them. *I'

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

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

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

Hello Daniel! Some time ago I started an open source project: Loginbuddy. Loginbuddy is a tool that mainly supports OpenID Connect based logins. It can be deployed as a standalone service or be used as a side-car next to other docker containers in the same network. Although it is not necessarily