Re: [OAUTH-WG] OAuth 2.1: dropping password grant

I'm a little confused on where this thread is going. If we take ROPC out of OAuth 2.1 then: 1) Existing deployments can keep using ROPC - why break it if it is working.. 2) New deployments can use ROPC and be OAuth 2.0 compliant. 3) New deployments that don't need ROPC can be OAuth 2.1 compliant

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

ROPC without a client ID or authentication is functionally equivalent to Client Credentials grant with client secret authentication in the request body. You've just renamed "client_id" to "username" and "client_secret" to "password". The AS simply needs to be able to resolve the client ID to the

[OAUTH-WG] More product group review comments on the OAuth 2.0 for Browser-Based Apps spec

More comments hot off the presses from a Microsoft product architect... https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-6.2

[OAUTH-WG] Review of OAuth 2.0 for Browser-Based Apps

I did a cover-to-cover read of draft-ietf-oauth-browser-based-apps-04. My review comments follow in three sections: substantive comments on the text, substantive overall issues to consider (provided by Microsoft product engin

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

I’m not really sure the WG should be telling people what they “ought to be doing” unless we have concrete security or interoperability reasons for doing so. I also don’t agree that people doing this are doing anything wrong. I don’t always agree with what our customers do, but I’ve learnt over

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

The AS doesn’t issue the service account IDs, that’s the whole point - integration with existing systems. Lot’s of people don’t have the luxury of rebuilding systems from scratch to fit in with the preferences of the OAuth WG. ROPC doesn’t require client authentication, or even a client identifi

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

+1. I’ve seen this anti-pattern deployed all over the place, and it’s time to get rid of it and send people toward what they really ought to be doing. Another thing I’ve seen is using different service accounts to get different sets of access for one client — if you’re doing that, you’ve got a c

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

The client IDs can still be opaque identifiers provided by the AS, they just happen to be associated with specific service accounts. Or they could be the opaque IDs that the AS already issued for the service account. Either way, the AS could issue a token with the appropriate subject and other c

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

It’s difficult to give advise without lot of detailed information. I nevertheless give it a try. Mechanically, the application would need to use a different grant, credential instead of ROPC. If such an application today already uses a distinct client_id, the AS must be set up to relate this cl

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

But we’re talking about existing deployments. Are you suggesting that people should bulk rename all of their clients to match the service accounts (or vice-versa)? — Neil > On 21 Feb 2020, at 14:54, Torsten Lodderstedt wrote: > > > >> On 21. Feb 2020, at 15:47, Neil Madden wrote: >> >> S

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

> On 21. Feb 2020, at 15:47, Neil Madden wrote: > > Sorry, I missed that message. > > While this may be a solution in specific circumstances, I don’t think it’s a > general solution. e.g. an AS may not allow manually choosing the client_id to > avoid things like > https://tools.ietf.org/ht

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Hello, I am new to the mailing list. I support a mTLS grant type. Client certificate and additional credentials in the request seems redundant. While using GCP, the flow seems to be signing a JWT with a private key known to google, which is then exchanged for a google signed JWT. Beyond the serv

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Sorry, I missed that message. While this may be a solution in specific circumstances, I don’t think it’s a general solution. e.g. an AS may not allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or may return

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

I see - we have gone full cycle :-) Annabelle’s proposal would solve that. Relate a client id to a service account and obtain the token data from there. > On 21. Feb 2020, at 15:31, Neil Madden wrote: > > Yes, that is great. But mTLS doesn’t support service accounts (!= clients). > Maybe it

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Yes, that is great. But mTLS doesn’t support service accounts (!= clients). Maybe it should? Should there be a mTLS *grant type*? — Neil > On 21 Feb 2020, at 14:20, Torsten Lodderstedt wrote: > > Have you ever tried the client credentials grant with mTLS? After reading > your description it s

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Have you ever tried the client credentials grant with mTLS? After reading your description it seems to be simpler than JWT Bearer. * work out if the AS even supports mTLS * work out how to configure the AS to trust my cert(s) * Create key pair and cert using openssl * Register your (self-signed)

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

No failures, but it is a much more complex grant type to set up, when you consider everything you have to do: * work out if the AS even supports JWT bearer and how to turn it on * work out how to configure the AS to trust my public key(s) - do I have to create a new HTTPS endpoint to publish a

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

> > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again then > we wouldn’t be having this conversation. So perhaps removing it is an > incentive to make that happen. > Neil could you elaborate more on this p