Re: [OAUTH-WG] Usage of Password Grant

Aaron Parecki <aaron@parecki.com> Sun, 10 May 2020 14:20 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7C63A09D2 for <oauth@ietfa.amsl.com>; Sun, 10 May 2020 07:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BR6IguRMFYy for <oauth@ietfa.amsl.com>; Sun, 10 May 2020 07:20:55 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31623A09D1 for <oauth@ietf.org>; Sun, 10 May 2020 07:20:53 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id u11so6779487iow.4 for <oauth@ietf.org>; Sun, 10 May 2020 07:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jRgCCz3zavzdc+Itnyd71jV0nEOpWwrpRE/hXzKoUnI=; b=1UIu4Mc6om+ojpZ9bfCtvXSso4gqPNlajZR5ZW1Gp4XI0bKiF0H2EhXF+4nMrd+Nbs o06Zfc/FE2S1+DLSbA1B3QfbJLvgUsMQKKdvGqlMltfXCT3ryaG0uW0469bH18iApft4 xIe6cha3HRofy2b35mTAOwFHXKn9Xny7YWJD3GE8jppR0ubaz9S0Ban4g/UTjM8ThFnv +c4Bh243DvG4eSJqFUs+NlXK/SIlb7TLhD3vT0jAczqzzfPq2O7UiXR7pOv8w4pEaa1l EMb8JVSsr7foHv0B3dSTtmo1Q+K7zNES9Z4qCcdYBApBawveP+WghteSNk7o1glgkBK4 QWZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jRgCCz3zavzdc+Itnyd71jV0nEOpWwrpRE/hXzKoUnI=; b=mLTFA1NfRJhh/w//iD5tuPuQrvj1rPDjBQ4RXjD4I0onaUpL0DJvx/QwhubwoawpkK C25nRR5wPRZYefKkjm+hl3C6JsrvCbCvLGJfPmOnzXGe5n5M4Za169RmPDoSnBRqI/Hj 55K9z6AoQ7IRxbl6birOXQeGp3D/2P9hBIdhkB5xo0p7JseVpUSNmd9rY+QjaNQa92Ai ZnxHnAUdy5Vy7S+J5C4BqWMprRyRUf39IWSAa2WYLS/08uptV3CexSPa0KxpzExi+jyC szJyX06ifIjWMUV4G2msuum4Bn4aje9x4jdu8FYJvdigzxVNBkvBemh/ySDYqapO5hR+ X1ug==
X-Gm-Message-State: AGi0PuZs+tfStz98TyMYY3AYp9lRacW22HEah3X3YHwUCH7A9Kkb5toU Syt84QcqXpPZboMZ8b3K/zO/P+TD0Pg=
X-Google-Smtp-Source: APiQypLHe++WSDHky6tifNtEvlM/fKzEgpn2Opl+XFnYlOvSBSfJV2zp53x3Zmn9mouWSWu7mkJuzQ==
X-Received: by 2002:a5d:8e0d:: with SMTP id e13mr11340735iod.132.1589120452406; Sun, 10 May 2020 07:20:52 -0700 (PDT)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id u21sm3354622iot.5.2020.05.10.07.20.51 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 07:20:51 -0700 (PDT)
Received: by mail-io1-f41.google.com with SMTP id w11so6752563iov.8 for <oauth@ietf.org>; Sun, 10 May 2020 07:20:51 -0700 (PDT)
X-Received: by 2002:a05:6602:1303:: with SMTP id h3mr11127875iov.14.1589120450800; Sun, 10 May 2020 07:20:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAB=KHVUNv9op+kniNuaUJyPKhWQLSYjOfFb+g=4Tg1n4t08ixw@mail.gmail.com>
In-Reply-To: <CAB=KHVUNv9op+kniNuaUJyPKhWQLSYjOfFb+g=4Tg1n4t08ixw@mail.gmail.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Sun, 10 May 2020 07:20:39 -0700
X-Gmail-Original-Message-ID: <CAGBSGjqAJ9X7CU_csBJ-eHQQJKCLa4JuR-eqK=2qFURfdLT36g@mail.gmail.com>
Message-ID: <CAGBSGjqAJ9X7CU_csBJ-eHQQJKCLa4JuR-eqK=2qFURfdLT36g@mail.gmail.com>
To: Beena Santhosh <beenapurushothaman@gmail.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f9b2e605a54beff6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Ll_dd3K-Xvg-ocIuFae4SUVAZFU>
Subject: Re: [OAUTH-WG] Usage of Password Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 May 2020 14:20:59 -0000

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 <beenapurushothaman@gmail.com>
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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>