Re: [OAUTH-WG] Rotating client secret
Warren Parad <wparad@rhosys.ch> Mon, 13 July 2020 22:50 UTC
Return-Path: <wparad@rhosys.ch>
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 C11E53A005F for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 15:50:36 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys-ch.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 vG1nhI_Ndmki for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 15:50:33 -0700 (PDT)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 32DF93A0062 for <oauth@ietf.org>; Mon, 13 Jul 2020 15:50:33 -0700 (PDT)
Received: by mail-qv1-xf2a.google.com with SMTP id p7so6619201qvl.4 for <oauth@ietf.org>; Mon, 13 Jul 2020 15:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys-ch.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VOLfjXI8eqPSz4Wp5YyBoN75MS9xS19pqjXRFQd+yhQ=; b=YOgFIe/DKU01SuhuXhSGapy8XC1wCKhGZZ52qWiXervg5gNzaehAuPOsrUZogqLgbq MC0yLoWipDJL61jtioPndmHz68sW/r1JTj+CXxnEX0tAdBrZWpVHOcKIxq9KonNaCZbG CBtkOuBzlVVmdbHUUKw7eSUEqZ2B53aWhO06eEMXQAk0TAR2oiR8dKaVJKnh+jqMKDzC z4KIyJy3oKvZSmhya/AgrX2mE/PAVouybHZB6zTHC5VJkRsfJBwZNVPIYVbQ30UgIESW DuD9HCu9jjatF/Joz3zAPBTj2SUCwKFTI9uAkEfca8oYRQAtj4eYhElmupW6cQjGfEnf xJhQ==
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=VOLfjXI8eqPSz4Wp5YyBoN75MS9xS19pqjXRFQd+yhQ=; b=ptL6s6aC/ByCZj7EPrnnn8v+fPETxFQs27PGO6fQRMikZGvNAeNAXCpnJ63vo4WwOU f2rj5MRmNSiQdEfYyft/qpEmbdy4r5fHvS7SFIiT8P4/JtT8qo6uJcSHhtxLUGGGuWRk KNLwXJTJeqMPKGmGW/hCFrrwKv0dpqaxrGndlv1NIGibRe9MqtF8Q5aycjX4wXuOhESy 7xkyLVK14Nzf9fWg7Mi0ft0wD8tg0p1jNuC2HCA5ovz7x1td21s2mweGK+VaeNpG41yR WHd38agpaUDv8nw5YkzlWKgc9QqMoArJ18G2cUuMIhYZn9NNc4+islxYN3VoPXSXmJnh cFpA==
X-Gm-Message-State: AOAM530HBl8WxHVsiDq1k+hWIE1gNfrUpIWzb3RNaQr2+Hum2BWsEEDI P/tXAEVl1ZDyb4t5FWEXuI1UcKCwZxY3ctxyXUpN
X-Google-Smtp-Source: ABdhPJxHurSt57QmaH20rlM8K6pJ1bazPF5y6rlbNFQwognZj8FLsbQX0+nWxYi0qVhfTToPG+Q4Vxqx+IGMJ+3eCdc=
X-Received: by 2002:ad4:57c7:: with SMTP id y7mr1781274qvx.124.1594680632124; Mon, 13 Jul 2020 15:50:32 -0700 (PDT)
MIME-Version: 1.0
References: <7619889F-6A75-4179-B4A8-DEAAC359E5EB@broadcom.com> <CAJot-L2ci3uf2TcP_6jWP5ExwBCam=pTLAOQOKnDperG7NwzCg@mail.gmail.com> <BF20EE1A-F070-4E27-B13D-97DA70676ADB@broadcom.com>
In-Reply-To: <BF20EE1A-F070-4E27-B13D-97DA70676ADB@broadcom.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Tue, 14 Jul 2020 00:50:21 +0200
Message-ID: <CAJot-L0jsX8Gzr2xMo1E7=q0H4H694UQW3eOHAoRapezofEW7w@mail.gmail.com>
To: Amarendra Godbole <ag@broadcom.com>
Cc: Amarendra Godbole <ag=40broadcom.com@dmarc.ietf.org>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009bbfae05aa5a84f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AI_-1J3Z6w3HCj_LVRGBUBn3Fvo>
Subject: Re: [OAUTH-WG] Rotating client secret
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: Mon, 13 Jul 2020 22:50:37 -0000
Why is #3 a problem, and why do the admin A incorrectly use App A to store the service credentials of App B in their repository? Admin A should be using their source control/database to store the tenant B client secret. *Warren Parad* Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>. <https://rhosys.ch> On Mon, Jul 13, 2020 at 11:34 PM Amarendra Godbole <ag@broadcom.com> wrote: > Let me see if I can provide more details on the usecase: > 1. A tenant is subscribed to SaaS application A and SaaS application B, > and both applications are separately managed by different teams in the same > organization. No assumption can be made about the trust between those teams. > 2. Application A backend is supposed to access Application B. App B also > has the authorization server. Both applications expose administration UI > for its tenants. > 3. App B admin generates client_id and client_secret, and hands them over > to App A admin. > 4. App A admin enters the client_id and clilent_secret in the UI, so the > backend App A can now communicate with/access App B. > > #3 exposes client credentials of App B to admins of app A — *this is our > problem*. As stated in #1, we cannot make any assumptions about the level > of trust between the two groups. > > If OAuth2 provided a client credential rotation, this exposure of > credentials can be limited to a small time window. The original > client_secret can be a one-time-use-bootstrap, that App A backend exchanges > for another secret from the authorization server. Generalizing it, the > OAuth2 spec can provide for servers to trigger a client_secret rotation. > > To your analogy, the front-end app can “leak” the credentials during > provisioning (it can be a simple copy/paste that the user has to do), thus > creating a security issue. But if the credentials are one-time-bootstrap, > then first time the front-end app connects to Google drive, drive changes > the client_secret for a different one, which then would be used by > front-end app in the future. Drive also has the ability to periodically > rotate the client_secret in a similar manner. This assumes front-end app > cannot access the client_secret once it is provisioned. > > Is this better? Thanks! > > -Amarendra > > -- > sent via recycled electrons, from my portable command center. > > > > On Jul 13, 2020, at 1:48 PM, Warren Parad <wparad@rhosys.ch> wrote: > > I'm not sure if it is just me, but I'm not sure I'm totally following. > > I can see a concrete analogy being that, Tenant application B could be > Google Drive, and Tenant application A being any front end app that wants > to offer a service that saves files in a user's Google Drive. If > application A wants to interact with application B offline then tenant A > needs a service client/secret along with an authorization grant initiated > through application A (currently via UI in OAuth2). > > Whether application A cycles the client secret or not seems like a > different problem. But I think I'm missing something. Given the example I > provided, would you be able to provide more insight into the problem you > are seeing? > > > *Warren Parad* > Secure your user data and complete your authorization architecture. > Implement Authress <https://bit.ly/37SSO1p>. > <https://rhosys.ch/> > > > On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole <ag= > 40broadcom.com@dmarc.ietf.org> wrote: > >> Hi All, >> >> First post to the list, and hopefully I am articulate enough to describe >> the problem I am facing — did OAuth ever consider an ability to dynamically >> rotate client secret (part of the “client credentials” authorization >> grant)? I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration >> Protocol), but the OAuth 2.0 implementation I am looking at [1], does not >> support it. I also found some previous reference to client secret rotation >> [2], but it does not discuss my use case. >> >> We operate a SaaS application A, which is supposed to talk with another >> SaaS application B. Our customers subscribe to both, our application A as >> well as application B. However, the teams adminstering A and B are separate >> teams within the same organization, though we cannot assume the level of >> trust between them. Let’s call them Tenant Admin A and Tenant Admin B. In >> our usecase, application A is the client for application B, and application >> B provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to >> provision the "client credentials” authorization grant — in order to do >> that, Tenant Admin B generates the client_id and client_secret, and sends >> them to Tenant Admin B. There is the problem — as I earlier stated, we >> cannot assume the level of trust between Tenant Admin A and Tenant Admin B, >> and exchanging client_id and client_secret now means the circle of trust >> for application B includes individuals who may or may not be trusted. >> >> One thought that occured to me was a provision in OAuth 2.0’s client >> credentials grant flow was the ability to “bootstrap” a client application >> — basically the client_secret is one-time-use-and-timebound-only, and >> allows the client to exchange it for a different client_secret. In our >> case, this can be handled by the SaaS application backend, thus making sure >> the Tenant Admin A no longer have access to it once they provision the >> client. This can be generalized, such that the authZ server can >> periodically trigger client_secret rotation, and won’t require manual >> intervention [3]. As I stated earlier, rfc7591 talks about this, but but in >> the context of dynamic registration. >> >> Having the client secret rotation a part of the protocol exchange >> messages, maybe a bootstrap, would be the ideal solution for our usecase. >> >> Or the bigger question: Did I misinterpret it all? Looking for guidance >> from this list. >> >> Thanks in advance. >> >> -Amarendra >> >> [1] Microsoft Azure >> https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-app-types >> [2] >> https://mailarchive.ietf.org/arch/msg/oauth/7ICMSRI2tjfXDD1Bk_G-qNpLy-0/ >> [3] Auth0 rotate client secret: >> https://auth0.com/docs/dashboard/guides/applications/rotate-client-secret >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
- [OAUTH-WG] Rotating client secret Amarendra Godbole
- Re: [OAUTH-WG] Rotating client secret Warren Parad
- Re: [OAUTH-WG] Rotating client secret Amarendra Godbole
- Re: [OAUTH-WG] Rotating client secret Dick Hardt
- Re: [OAUTH-WG] Rotating client secret Warren Parad
- Re: [OAUTH-WG] Rotating client secret Amarendra Godbole