Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body

Brian Campbell <bcampbell@pingidentity.com> Thu, 25 January 2018 14:28 UTC

Return-Path: <bcampbell@pingidentity.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 713B312D954 for <oauth@ietfa.amsl.com>; Thu, 25 Jan 2018 06:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 zdrwqEFJdRJo for <oauth@ietfa.amsl.com>; Thu, 25 Jan 2018 06:28:05 -0800 (PST)
Received: from mail-io0-f193.google.com (mail-io0-f193.google.com [209.85.223.193]) (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 7FC32120726 for <oauth@ietf.org>; Thu, 25 Jan 2018 06:28:05 -0800 (PST)
Received: by mail-io0-f193.google.com with SMTP id b198so8811191iof.6 for <oauth@ietf.org>; Thu, 25 Jan 2018 06:28:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Db/j2QGnPG1RoFJC3gufip+7Tc6zKJskOjBptgAvmH4=; b=YfFNkHzksh1NVX7MN42i43YsTnjHCb+pOGNYWjQ30O0ow+9qmtL5FfG4DwidbF3mMb 0wgDEKZiAp6M2DPmfdGw+zwFQrwr/JKpyF8HJvRuV2dF18zuWRJTy/Wb06E6TEb+XA4V eR+NOLCMwBfBEyCwTYAcEKhyPHAuWxrCN/p5g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Db/j2QGnPG1RoFJC3gufip+7Tc6zKJskOjBptgAvmH4=; b=HSZ/DCR44t8J5Dq5uDJBBUqFfg+/iKyjqZZJQqJbLr5eJKkL/GGBuXrD3brh4OK2IZ sVvEtPOBANWCNPN37kYP7327Dr+f8UHgAWMqKdWRF+a+GYdHL9KryVWc/YsG23JPsmt+ QQWNRtYUByu5wtH4C3xFXcKnHw8+tCbDaMniLHgZwxL6iOIUjY6LPItqOQ5ZtEW4zd8u UXOH/vc6XM9s/3O/sUirfS+S0Odf0DGrq3qYDp7neSVyi30gx8ZXe7s8NaIDRFu2YHKm v5WJcNVN8HzPvIsRbgFVqNuRxQMuz2/d3wUZ4krjY8jP5Vs2Bl54UF6iwHo1NuPFy1fZ /X4w==
X-Gm-Message-State: AKwxytcEpv7yV+2crLkNBeLvIxMNgSY1S7LMbkOwN6kR9X1uyHK+Rc7/ coMsoQOIEhnfLA53td+GFB/GP0NgYkwMksre40IG0XiksuApMrtwbFigy2SOgNpWk05s09VeqkG nAJZe/Bv8J6jN/YZT
X-Google-Smtp-Source: AH8x227h8rsQf79Cp06mZfEfCYWEdIbLbJlD3RPr5ClU9yeAfk9lJWG04yV5BEGKD2dvpSrooq3QOP85z1zx8LRstnE=
X-Received: by 10.107.155.16 with SMTP id d16mr12828377ioe.247.1516890424216; Thu, 25 Jan 2018 06:27:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.108.210 with HTTP; Thu, 25 Jan 2018 06:26:33 -0800 (PST)
In-Reply-To: <OFC97C8467.B35570A3-ON8025821F.00389998-8025821F.0038B8AA@notes.na.collabserv.com>
References: <OFC97C8467.B35570A3-ON8025821F.00389998-8025821F.0038B8AA@notes.na.collabserv.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 25 Jan 2018 07:26:33 -0700
Message-ID: <CA+k3eCRTP1iZV4+nW1zFgNFhu4_LONL6vnj0WSsvHipwMdLO6Q@mail.gmail.com>
To: Tom Van Oppens <Tom.Van.Oppens@be.ibm.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141bc1ee6911005639a92fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6m-giYhoFm1P10pkmEOTCT7m8D4>
Subject: Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 25 Jan 2018 14:28:08 -0000

Hi Tom,

Indeed RFC 6749 is not well written with respect to this situation and
unfortunately leaves some room for varied interpretations. However, in my
own not entirely uninformed view having worked on this stuff for awhile
now, it is erroneous to interpret the presence of the client_id parameter
in the request body as client_secret_post authentication when there is no
corresponding client_secret parameter. As you alluded to, there are other
types of client authentication that explicitly allow (JWT
<https://tools.ietf.org/html/rfc7521>, SAML
<https://tools.ietf.org/html/rfc7522>, and their base spec
<https://tools.ietf.org/html/rfc7521#section-4.2>) or require (MTLS
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-06>) the client_id
parameter and the OIDC core spec even has an example of the client_id
parameter in the body
<http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication>
when doing JWT client auth. If client_id with no client_secret in the
request body actually implies client_secret_post, then those RFCs (one soon
to be RFC) and OIDF standards are all contradicting OAuth 2.0 /RFC 6749.
Those supplementary standards as well as widespread
implementations/deployments in practice should, I believe, be considered
more authoritative than one particular implementation's problematic (in
terms of interoperability) interpretation of a not particularly well
written area of the OAuth spec.

The problematic text from https://tools.ietf.org/html/rfc6749#section-2.3.1
says that "the client MAY omit the [client_secret] parameter if the client
secret is an empty string" so it would only really be reasonable for an AS
to reject a request as having two client authentication methods in the case
that it issued a client the empty string as a client secret (not a public
client but a client with an empty string as its actual secret), which
should never happen in practice, and that client sent both a basic
authorization header without a password and a client_id without a
client_secret in the body. That's one way to read it anyway. And regardless
that text in Sec 2.3.1 is problematic and should probably be updated with
an errata on RFC 6749 to get rid of the text about empty string password
and just state that the client_secret parameter is required when doing
client_secret_post authentication. Unfortunately the errata often get
overlooked but it'd still be good to have that fixed somewhere and a
published RFC can't be changed so errata is the only real option to
document the actual intent of the original specification.

The presence of the client_secret parameter should be the only thing that
implies client_secret_post authentication.

If a client_id parameter is present in conjunction with some client
authentication mechanism, then both must refer to the same client.




On Wed, Jan 24, 2018 at 3:19 AM, Tom Van Oppens <Tom.Van.Oppens@be.ibm.com>
wrote:

> Dear Oauth Mailing List
>
> After some discussion i had i wanted to ask you for some guidance.
>
> For the following request
>
> *request_uri*
> https://example.com/token
> * request_method*
> POST
> * request_headers*
> {"Accept":"application/json","Authorization":"Basic
> bWFnaWNpZDpwb3RhdG9zZWNyZXQ=","Content-Type":"application/x-
> www-form-urlencoded","Content-Length":"91"}
> * request_body*
> grant_type=client_credentials&scope=accounts&client_id=magicid
>
> We had some discussions whether or not this request is a valid request, to
> be more exact wether the clientid can be in the body.
> Section 2.3.1 states
> *A client MAY use the "client_id" request parameter to identify itself
> when sending requests to the token endpoint. *
>
> But at the same time in the case of a client password (2.3.1)
> The clientid and secret are carried in the basic auth header as a form of
> authentication as a preferred method ,
> But the standard states that if you choose to use the body as a form of
> authentication that if you can ommit the clientsecret the clientsecret is
> an empty string, therefore passing only the client_id is the same as
> passing the client_id and an empty string clientsecret .
>
> So the current request would be according to the spec interpreted as
> follows
> Authentication 1) basic auth cleintid:secret
> Authentication 2) body auth  clientd and blank secret
>
> You can choose to use the client_id in the body with public clients or in
> the confidential client (the Lloyds situation) if you choose to add the
> clientsecret there as well and are not using the basic auth header (this is
> due to spec section 2.3 which states
> *The client MUST NOT use more than one authentication method in each
> request. *
>
> In short there is no way in the spec that allows for the oauth provider to
> distinguish between your intention of sending in the client_id again for
> identification and a malformed request with double authentication.
>
>
> So my stance is (for now) that you cannot send a clientid when you find
> yourself in the clientid with a corresponding password situation.
> Is that a correct statement ?
> and if it is not how would that work ?
> and if it is, when can you send the clientid in the body but use something
> else for authentication  (something like mtls ?) ?
>
> Kind Regards
> Van Oppens Tom
>
> Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus:
> / Unless otherwise stated above:
>
> International Business Machines of Belgium sprl / bvba
> Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan,
> B-1130 Bruxelles/Brussel
> N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
> RPM Bruxelles / RPR Brussel
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*