Re: [OAUTH-WG] Usage of Password Grant

Beena Santhosh <> Fri, 15 May 2020 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5CF33A0BB3 for <>; Fri, 15 May 2020 09:13:38 -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 fkqWG2O2UTzz for <>; Fri, 15 May 2020 09:13:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D09F03A0C00 for <>; Fri, 15 May 2020 09:13:36 -0700 (PDT)
Received: by with SMTP id i68so2398634qtb.5 for <>; Fri, 15 May 2020 09:13:36 -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=/FP3JABfq287i6rqFVlg+7XoKSkLb/pO/crYGT5rogc=; b=Upq8yQYbuy/uriVGl6sFhff9rGDmyiDZWeCXjGHM1kgFTwAHV6azvYGiqYBu4GsCPk M6ACgybhy6LKCAv9gcX+mo77ZUyFP0MGSv01UkxCDA/NgVf0WbQfn4BZoVcLUw3k0jqj j5Lh+c029rcZ+cHO7fCdnKz4sl64/LuPj1clBqtIStWgzPH+RA2f0wOOLFrVPKcxfCCZ B3QQmvO4FAVnbch3XtXDK5kD25jG1DdLdy80xxJlSAxYjL7JLAyl85KRxilZVp8pOLmM MpQVJE5Bd9LJOZB1sC7bTz5vPQEkR3iWurIT1Ss8nyvPgoRt8P/ThtQRwo88TcY5vOXi wrrA==
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=/FP3JABfq287i6rqFVlg+7XoKSkLb/pO/crYGT5rogc=; b=XVw8Q7qCp/qzqlsOVKBHgcau+cwu9Fn3qF5pH0WYiaJf5XrCl4iDZYme0/6ZEcQxgG Pt03gL48SdF9OsR1UpNDyIiewMaVqXE1F47cKm9GC2EclTRsKRAU1xrCMW0RJANde8S5 5hKBHMLPgAHQQjBY4YORQqQK5ZghAtcdRaYlmnKaiZFfUD3NQco60YSGAqrLHnArBsrf pvqaurGdIpwYRGaHOKPpHm8rFaiNE6iAw1h8fdarceBM5zyqAdbKM2UpwEzeU1lfDWb5 kUlazKt/WTIeGD55pG+ZrGHuSMlFBKMu1pAXfy/xRumJksR5akYABikE01ErwpSz/GCr nvzw==
X-Gm-Message-State: AOAM531DmckViHXGUH6urROjiGE8vg04KD1EraWTjJa3ZJC/2gb5/wS2 iAP7W0K8Wa1bWx+otNUrqp81C8apgC4LupnareU=
X-Google-Smtp-Source: ABdhPJzu/Mhkb0+MQk+yy6g8Z9ClKSS7qEde/6OWdj6nn1XmKcr67P+BnEhjkHd9XjAq9KIgnBNRRKnPQ/WtILYx+jY=
X-Received: by 2002:ac8:39a4:: with SMTP id v33mr4404087qte.251.1589559215811; Fri, 15 May 2020 09:13:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Beena Santhosh <>
Date: Fri, 15 May 2020 21:43:24 +0530
Message-ID: <>
To: Aaron Parecki <>,
Content-Type: multipart/alternative; boundary="00000000000068754405a5b218d1"
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: Fri, 15 May 2020 16:13:39 -0000

Hi Aaron,

I had a re-look at this and the difference I still see is that I am able to
use a common client_id with Password Grant, which does not seem possible
using Credentials Grant. Without Password grant I don't see a way to
achieve this.

Thank You,

On Tue, May 12, 2020 at 12:40 PM Beena Santhosh <> wrote:

> 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
> tokens
> Thank You,
> Beena
> 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