Re: [OAUTH-WG] Authz Header + client_id in message body

Brian Campbell <bcampbell@pingidentity.com> Thu, 01 August 2013 13:57 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 E794A11E810F for <oauth@ietfa.amsl.com>; Thu, 1 Aug 2013 06:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.868
X-Spam-Level:
X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fDo7JKgTVuz for <oauth@ietfa.amsl.com>; Thu, 1 Aug 2013 06:57:47 -0700 (PDT)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id A6C8911E8118 for <oauth@ietf.org>; Thu, 1 Aug 2013 06:57:46 -0700 (PDT)
Received: from mail-oa0-f47.google.com ([209.85.219.47]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKUfppWR3Ngfoj7AaAVUuO2BLOjQ/0og18@postini.com; Thu, 01 Aug 2013 06:57:46 PDT
Received: by mail-oa0-f47.google.com with SMTP id g12so3840708oah.20 for <oauth@ietf.org>; Thu, 01 Aug 2013 06:57:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wbfKG69QwBDBWS/1BeNeshx3zenOMxFDaNbSPYU7xo8=; b=OZaUdDWWN/9t3Ecaq7uC/D8N0WgOxjs4vnIFDKiqF2ajUx59WlHTiRenYWq8RwLTvy 0mlRak8OCkZn3P5qZ8KaKkfXV9UlzyUVFKOPplP5gY+FToSC3LBENGAU8YiQIwdouwq/ UI+D+OxM110N4pdjGaSm6f+iBC4fjrPXAaxKrIonPeWRi7uM7ts80jhetWRmu3exV67C 0knjkaXDTE6CzRjTiNW8DeGSOqumgekvTeMgGohEK0zLmBiBRwfeD5QFjYONut7wnIx0 B6Yc2gXsGNfgKKua2lx1j+o+3WSy8MmzPAozPLFeedvxYsin06jlDk7uNxiPqcp0Y5KZ CTsw==
X-Received: by 10.50.60.103 with SMTP id g7mr1261082igr.47.1375365464908; Thu, 01 Aug 2013 06:57:44 -0700 (PDT)
X-Received: by 10.50.60.103 with SMTP id g7mr1261080igr.47.1375365464824; Thu, 01 Aug 2013 06:57:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.41.34 with HTTP; Thu, 1 Aug 2013 06:57:14 -0700 (PDT)
In-Reply-To: <706472E2-DF7D-4963-8C07-552F3690D927@ve7jtb.com>
References: <e1cdc1b2a4d1841d12938a900355121f@lodderstedt-online.de> <706472E2-DF7D-4963-8C07-552F3690D927@ve7jtb.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 01 Aug 2013 15:57:14 +0200
Message-ID: <CA+k3eCR+0MCLC5F5ZtAt28vcn0mCfM9kHOHcc2nO4BQY3vt73A@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="047d7b1117c1f7b3e504e2e339a7"
X-Gm-Message-State: ALoCoQlu5wtwUBKD+OyZhK+e87LtUkscMmVKPPFjbK/CNq65DwjpeDovH+7ZzTe/8gMrZ28THSj/Wb0HELVqacDCijD5zth+DJ5xwpm3aIXgPPCSYLRM7I2Moe/UKgQztzcn43VG+wCZL7+fIXYyaOXn26BtRsL8fw==
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authz Header + client_id in message body
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 01 Aug 2013 13:58:05 -0000

I thought I remembered that text from RFC 6749, section 3.1 as saying that
a *public* client MAY use the "client_id" request parameter to identify
itself...

Apparently that's not what it says. But I believe that was the intent - hat
a client with no means of authentication could identify itself by sending
only the "client_id" request parameter to the token endpoint.

Sec 2.3 (http://tools.ietf.org/html/rfc6749#section-2.3) says, "The client
MUST NOT use more than one authentication method in each  request."

And 5.2 (http://tools.ietf.org/html/rfc6749#section-5.2) has

         "invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter value (other than grant type),
               repeats a parameter,* includes multiple credentials,*
               utilizes more than one mechanism for authenticating the
               client, or is otherwise malformed."

There is some room for ambiguity in all that but, based on the above, I'd
say that the way your server is behaving is correct Torsten.



On Thu, Aug 1, 2013 at 2:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> Hmm allowing sending the client_id even if there is no authentication was
> intended to mitigate cases where the client presenting the code or
> refresh_token was not the one that requested it, and for logging.
>
> I don't think the intention was to allow the client_id to be sent twice.
>
> If it were my Token endpoint I would ignore the extra one and only
> processes the one sent as part of the authentication,  if there is no
> authentication then the value of the "client_id" parameter MUST match the
> client_id that was used to request the token.
>
> It is probably a open question if the request should be considered
> malformed if it contains both.
>
> Personally I would recommend that the client not do that.
>
> Others may remember it differently.
>
> John B.
>
> On 2013-08-01, at 11:34 AM, Torsten Lodderstedt <torsten@lodderstedt.net>
> wrote:
>
> > Hi,
> >
> > while setting up our OIDC interop tests, we run into the following
> problem:
> >
> > The test client sends a request to the token endpoint, which contains
> the client credentials in an authorization header. Additionally, it adds
> the client_id to the message body. Our server treats this as an invalid
> request and responds with HTTP status code 400.
> >
> > Now my question: The last paragraph of RFC 6749, section 3.1 (
> http://tools.ietf.org/html/rfc6749#section-3.2.1) states
> >
> > "A client MAY use the "client_id" request parameter to identify itself
> >   when sending requests to the token endpoint."
> >
> > This seems to allow the client to send the client_id in addition to any
> other credential used to authenticate it.
> >
> > I'm not sure what the intension is/was. How is the server supposed to
> handle such cases? Shall it compare both ids (from the header and the
> body)? Must they match exactly?
> >
> > Any feedback is appreciated.
> >
> > regards,
> > Torsten.
> > _______________________________________________
> > 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
>
>