[OAUTH-WG] Client authentication on token revocation
Emond Papegaaij <emond.papegaaij@gmail.com> Thu, 20 August 2020 09:02 UTC
Return-Path: <emond.papegaaij@gmail.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 604A33A0A40 for <oauth@ietfa.amsl.com>; Thu, 20 Aug 2020 02:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ypThZVtIKTDa for <oauth@ietfa.amsl.com>; Thu, 20 Aug 2020 02:02:24 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 2D1B03A0A3E for <oauth@ietf.org>; Thu, 20 Aug 2020 02:02:24 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id n128so1284297oif.0 for <oauth@ietf.org>; Thu, 20 Aug 2020 02:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Y3iI0vl26QYYGrkooGit465v2dZ13CCdZbpfY69ZD44=; b=jtAmMnV7qVsMi77jU3InLvzOj4M6zFhcQZaNA82rHan2OCA+NDGG1psAHjuOXu+UaN 6jdRZXCq/sacuD/pZLvgXC+R5NxH30pcQKinc9ko3MxBwsypk6mNhCvI03N4QE4HwreH uH5snpviETN+B9Z19AzXgQgE36WoWeNNLKuFecdGCnU61uWtG8IjG51wLy3A4Uad8khs 1uUovW1yW54m13zR5rsQWgYDPbaqLRqoE+MtNCZh06Xc+NdQWc/Fa40bXhopbh/GGNK8 LYEKcluC8izduYweFuwLTk+/4ZAhPd9CGCw/xM8iAB7fQ7ZIJZ6I6KtC1yk7p9tgF3u0 lapQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y3iI0vl26QYYGrkooGit465v2dZ13CCdZbpfY69ZD44=; b=av+vKb4jPJGzvEqp6UtL6t2Q0e6DIT9HAZpJlT6YrBfB6DBhX3vFbSuYTFNOIBBsSd AifIrTXzDzpc0iMc7P7yicv7QGCViWMcu8ooCTnrplypw81jzftEWSZfI8OzlFc1N3Lv SmQvh6sBUsT0Coqy4KY6i86OIoim2YT6F0vq/UBVGsZZJSdTtzzdeQDUw7STL7rUlWcP v93EMqqvlk6hLn4sI9GQctEgeJWUD3/IyRaa19orV8F4i3dXWQIXALNtRfL57pm5aT2F +a6JE5auv1peZensSH9v4uXWs4IYB/5S36ivpy5YKinF5QV50X3w8SPWIIRpSHtRsN2B IuHw==
X-Gm-Message-State: AOAM5322IoSnq+zFxv1Af+3tfhF+PpGoBxolcn3EuYhxNigDZVZ7LmAH KJFCqRvXM65YlBc54Btq9LIaFjWN2LYxVmbsqiKDH4ZuGP4=
X-Google-Smtp-Source: ABdhPJy+rAwUT4sis5Ij4b1Z65Em3Ijuy7riiYAU5dVBo1ZuWQQ0NshyJUSiTesB6dqgv5Ho+k2Zf6gzXFrbCdVVqHo=
X-Received: by 2002:a54:4588:: with SMTP id z8mr1163320oib.86.1597914143064; Thu, 20 Aug 2020 02:02:23 -0700 (PDT)
MIME-Version: 1.0
From: Emond Papegaaij <emond.papegaaij@gmail.com>
Date: Thu, 20 Aug 2020 11:02:12 +0200
Message-ID: <CAGXsc+Z6rYsktb+bokg6i2myG_FB4cWHrfX5+d6bQW+LcWg=ig@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I>
Subject: [OAUTH-WG] Client authentication on token revocation
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: Thu, 20 Aug 2020 09:02:25 -0000
Hi all, We are currently implementing the token revocation endpoint (RFC 7009) on our authorization server and do not understand why it requires client authentication. When a party (a valid client or not) gets hold of a valid access token in whatever way, the least damaging it could do with it, is to revoke it. The current spec allows an attacker to misuse this token for access to the resource server, but forbids it to revoke it. This seems strange to me. Section 5 of RFC 7009 does not help in this either. It starts to explain that this authentication is needed to prevent malicious clients from guessing tokens, but ends with the fact that if this were possible, much worse damage could be done by using the guessed token on the resource server. We plan to skip the authentication all together and simply revoke any valid token presented. How would you recommend we deal with this? Best regards, Emond Papegaaij Topicus KeyHub
- [OAUTH-WG] Client authentication on token revocat… Emond Papegaaij
- Re: [OAUTH-WG] Client authentication on token rev… Torsten Lodderstedt
- Re: [OAUTH-WG] Client authentication on token rev… Emond Papegaaij