Re: [OAUTH-WG] Usage of Password Grant

Beena Santhosh <> Tue, 12 May 2020 07:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B97B53A0887 for <>; Tue, 12 May 2020 00:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vpfWulX-NSij for <>; Tue, 12 May 2020 00:10:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF67D3A0885 for <>; Tue, 12 May 2020 00:10:22 -0700 (PDT)
Received: by with SMTP id v4so9302943qte.3 for <>; Tue, 12 May 2020 00:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WXwZGMPT2bOpvnzxVYt+O82FHrgOzbzJfDY4qZB5QYE=; b=mv8dagMq3US90XHCiouMvH8LWFPfI0vCXc4g3wu/EkDl3gj3F+rvuhaJmi75QlUsFl PNtDa1y6J6D/xb6FzsOa2hkmdRoyxCVlj376qr4YpSPRI3ckbhkuyax84wlhyZHZ/mUu iYXUNl9UBR83I1WN04IspW2zS/ysZWSrnsJTbkdQRzdN6V1fxizvfnRXQkjmexNfXG54 iSJDzgtn6d069KbHt+IJPeiQPOYAyIFue1J+Y340G0dSkZugcx+sT+TkZTJkC0sC6hZI qf1pyCkTXWHNeuZsdU1txxCCbNvwf2L41LjCMKEFDLk0c6zs5KA/6+ugOubKeh/AApHQ Pk6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WXwZGMPT2bOpvnzxVYt+O82FHrgOzbzJfDY4qZB5QYE=; b=i150e179dInFn3ToqDK3FRwh2xEyPJXjQOFz8Q3BjiMG2gqJu2c42IHtGLPOyeftHR Vl/i/qJQ15bOveebyku18L+LhxDTLDbeTJiziyhaPP9Y9l4s9suAOaDx0YU960lOxco8 oxLepGjk5UJ5a+sFarTd5PcivfuVgflU72O8DxQejXk2+nGHLhebgVUnUUKGHtoVC0aD HP9bi0F+iXj/jRHOF3GagQNyxnOwQmz5eHeE0K1riofanjc5fq3EmtyDbG1XT2K7SbE8 1AqIR3arYuNFY2RCyRumPPdzCVARa1z5NQU0JALWmOjLbQHd846JIz/r8vpvpbM63b/0 H/gg==
X-Gm-Message-State: AGi0PuY4HobZ6mIPML3wFyimwwdQz+zlNeuc1smnXQw75OF3H09v0SOV 6IwmaHEeRvVf/QNwzwYctw8gskhhQGPHCp7FNYcmXRAZIjU=
X-Google-Smtp-Source: APiQypJ0DA9a/Ot14eGqpjoOgH71VKCpdoldSEOGZTQvaJoasD4BCgPeV348r9xaXL3XMP15zaL2g8RlaS+PTKVK6Jk=
X-Received: by 2002:ac8:7758:: with SMTP id g24mr19338102qtu.85.1589267421504; Tue, 12 May 2020 00:10:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Beena Santhosh <>
Date: Tue, 12 May 2020 12:40:10 +0530
Message-ID: <>
To: Aaron Parecki <>,
Content-Type: multipart/alternative; boundary="0000000000001cb08205a56e28c8"
Archived-At: <>
Subject: Re: [OAUTH-WG] Usage of Password Grant
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 May 2020 07:10:25 -0000

Hi Aaron,

What we are planning to build is a Public first party client. As per the
spec the client secret is optional for Password Grant. Hence we choose to
use a common client_id across all the devices. The first party client on
every device  will get the  common client_id through our proprietary API.
We found this as a difference between Password Grant and Client credentials
grant. We could be wrong but this is our interpretation.  This way we could
make use of the rest of the benefits that OAuth provides around access

Thank You,


On Mon, May 11, 2020 at 11:15 PM Aaron Parecki <> wrote:

> With the password grant you'd then need to register 50,000+ user accounts,
> right? How is that different from registering that many clients?
> On Mon, May 11, 2020 at 10:39 AM Beena Santhosh <
>> wrote:
>> Hi Aaron,
>> Thank You for the quick response.
>> We do support  1, 50, 000+ devices and that means we need to register
>> those many devices dynamically,  the provider we have evaluated  is not
>> supporting that scale . Once we  incorporate IoT, we need to support
>> millions of devices. With Password Grant as we need only one client_id it
>> is easy to manage. Also our client is First Party client.
>> Thank You,
>> Beena
>> On Sun, May 10, 2020 at 7:50 PM Aaron Parecki <> wrote:
>>> Hi Beena,
>>> This sounds like a great use of the client credentials grant. The
>>> password grant is being removed from OAuth 2.0 by the Security Best Current
>>> Practice. Can you clarify what you've found useful about the password grant
>>> that the client credentials grant doesn't solve?
>>> Aaron Parecki
>>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>>>> wrote:
>>>> Hi,
>>>> We have a product with client server architecture where our server
>>>> manages thousands of devices. Each device has a client-piece that talks to
>>>> the server over SOAP/REST. The client currently uses a HTTP Basic
>>>> Authentication (unique id and a secret string) for all the calls. The
>>>> secret string is created when the device enrolls to the server. It is
>>>> available at the server as well as stored securely on the device. For the
>>>> rest calls it is the device that is getting authenticated.
>>>>  Sending the credentials every time is less than ideal and we want to
>>>> move to some tokenized device authentication. We evaluated OpendID Connect
>>>> based on the general recommendation of SSO solution, but the issue is we do
>>>> not have any user interaction and hence there is no Grant flow that is
>>>> fitting. Hence we evaluated OAuth grant type of which we found Password
>>>> Grant and Client Credentials Grant is matching our requirement.
>>>>  In order to use Client Credentials in our use case, we need to do
>>>> dynamic registration for the thousands of devices managed by the server, if
>>>> IoT comes into picture the number is going to be even higher, which is
>>>> highly cumbersome to manage.  Also, as per  RFC7591 on dynamic client
>>>> registration, using access token for registering client is optional too.
>>>> Even though the Password grant is highly discouraged by the spec, we found
>>>> it to be highly matching with our requirements.
>>>> But as per the Oauth 2.1 proposal, password grant is going to be removed.
>>>> Can you suggest the way forward for us? I believe we are not a one-off
>>>> case.
>>>> Thank You,
>>>> Beena
>>>> _______________________________________________
>>>> OAuth mailing list