Re: [OAUTH-WG] client authentication

Filip Skokan <panva.ip@gmail.com> Tue, 17 September 2019 13:52 UTC

Return-Path: <panva.ip@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 CF28312084F for <oauth@ietfa.amsl.com>; Tue, 17 Sep 2019 06:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 K4226QjvpLRw for <oauth@ietfa.amsl.com>; Tue, 17 Sep 2019 06:52:53 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 35D82120801 for <oauth@ietf.org>; Tue, 17 Sep 2019 06:52:53 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id y39so3097025ota.7 for <oauth@ietf.org>; Tue, 17 Sep 2019 06:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZE7yKvjeU6gWYxNFD+ESMHHe4TdF6x6dmOx1aWTugyI=; b=heTAuv5tifYX3/nD6GE7xgNP++LfKr0FRAq6Oz0W1uXe7a+a/JcC+p+tv8NVYU2A9b QbdM1N4n6hltntTsrv6chn4iVRJ4NZ2Bfq8nEZh3t6mhO9Z3CX30+5mjZEsVGknSPfJ6 veePBCXUko3I10SwG1yzUwFCQzmCnH0XMMfcSTMr1IYvsLIdjPqcyXvoC91nUmQykATy hFJsrObPNQk2QL5YXm8pivI5NRZHhVHSIh3JnnYTtV5Ex0IsWLkSkdk5tDYdamratHXx nTA/G0PMMgx2qUFi9gX1add2nTf4lKLBV7wZkxA1Ot/K2BcoS8gLCLpQFtDCE4EQjlQY QtIA==
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=ZE7yKvjeU6gWYxNFD+ESMHHe4TdF6x6dmOx1aWTugyI=; b=e5hdehyG5+/SAdWrorjLt5RFIqbw9st9D/l2mZQHLYKrMdAWHSi4yT6FdL7LvwTB40 OifGC7CpmivI0f+qr7j77uLjb329EbRj40ikyUpYIVtAIotlRoykIu+kCqv0IFHRMxj2 5qa5EoTUtUNqnvpjZORYorbeIA87xZI93eV9NEZzVlCh7OH+puJt5z2DSiQYGgz81bzk IXf4z0oA3qQXu7D24nHjiwWiA10FNfw327nTm4xFUbZLF7RW+Kt5KC/9KlqVRtjLx8tE H9NgfyoSjZR0rDAhy3AaagUDo/PMMoU9klPC37TveLwoDdYoPzIo6+1GTEo5++y34CeY uGBA==
X-Gm-Message-State: APjAAAWJtsnKF64ktFwcxEfYg9pkT89Axokkq0iOkmY1XwcVc3KtN19d VFpQKfPCl2aXoQV22oUptz6E4uCTcfcqahatlIiwyG2+hw==
X-Google-Smtp-Source: APXvYqz6J3w2GZS/dlSZl2KRZT/mPT6J5NZ6cEhSWbkU+ecJGDu8eLlJ+QTKi1ZOw/PxFTEtMwNE3rAwq+93HWl6uRM=
X-Received: by 2002:a05:6830:10cf:: with SMTP id z15mr2643158oto.257.1568728372368; Tue, 17 Sep 2019 06:52:52 -0700 (PDT)
MIME-Version: 1.0
References: <2425F057-E2D8-46C3-A859-060245C309BB@iWelcome.com>
In-Reply-To: <2425F057-E2D8-46C3-A859-060245C309BB@iWelcome.com>
From: Filip Skokan <panva.ip@gmail.com>
Date: Tue, 17 Sep 2019 15:52:41 +0200
Message-ID: <CALAqi__e-rwWk5uYJaKKvM-NEE-Mh5Pg4t6J4kurcRyAfhE48g@mail.gmail.com>
To: Jaap Francke <jaap.francke@iwelcome.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006258f70592c00936"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gd75qHPX0R-C5xMVWAjHqEOaJpw>
Subject: Re: [OAUTH-WG] client authentication
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: Tue, 17 Sep 2019 13:52:56 -0000

Hello Jaap,

There are currently 7 registered
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method>
client authentication methods that are defined by various RFC's.

There are the three from RFC6749 which got their names registered in
RFC7591 - none, client_secret_basic and client_secret_post. (Please note
that RFC2617 IS NOT EQUAL to client_secret_basic - there are additional
requirements when it comes to encoding the username:password tokens defined
RFC 6749 Appendix B)

Then the two _jwt ones from RFC7523 that got their names registered as part
of OIDC Core 1.0 (yes, they're the same).

The two remaining are from draft-ietf-oauth-mtls and use mutual-TLS client
certificates for authentication.

RFC6750 does not define client authentication method. It defines different
means of using a Bearer Token obtained through any of the available flows
to access a protected resource.

Ad RFC7662) its at the discretion of the AS to require either a Bearer
Token or Client Authentication to access the introspection response, it may
or may not support both in which case the claims it returns may be limited
and also the means of obtaining that Bearer Token is out of scope of the
document.

Hope this helps,

Best,
*Filip*


On Tue, 17 Sep 2019 at 15:21, Jaap Francke <jaap.francke@iwelcome.com>
wrote:

> Hi all,
>
> I was exploring the topic of client authentication in various RFCs.
> A few things are not 100% clear to me, I would be interested to get your
> feedback.
>
> RFC7591 sets up the registry for client authentication methods on the
> token endpoint and adds:
> - none
> - client_secret_basic (RFC2617)
> - client_secret_post (RFC6749)
>
> I don’t understand why that registry seems limited to the token-endpoint.
> Client authentication also applies to other protected (OAuth) endpoints
> such as token introspect, so it makes sense to have a generic (OAuth)
> client authentication method registry.
>
> OIDC specs indicate a few more:
> - client_secret_jwt
> - private_key_jwt
> Is my understanding correct that client_secret_jwt refers to the same
> client authentication method as described in
> https://tools.ietf.org/html/rfc7523#section-2.2 ?
>
> Furthermore there is RFC6750 which suggest 3 client authentication
> mechanisms which are not included in the registry:
> - Bearer / authorisation request header
> - bearer / URI query parameter
> - bearer / form encoded body parameter
> For example, the RFC7662 suggests to use the “bearer / authorisation
> request header” mechanism as client authentication/authorisation mechanism.
> Any reason why this was not done?
>
> Thanks in advance for any related feedback, regards,
>
> Jaap Francke
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>