Re: [OAUTH-WG] Authz Header + client_id in message body
Brian Campbell <bcampbell@pingidentity.com> Thu, 22 August 2013 17:34 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 14E5711E80F3 for <oauth@ietfa.amsl.com>; Thu, 22 Aug 2013 10:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.797
X-Spam-Level:
X-Spam-Status: No, score=-5.797 tagged_above=-999 required=5 tests=[AWL=0.179, 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 zDSAUm0yt7ah for <oauth@ietfa.amsl.com>; Thu, 22 Aug 2013 10:34:27 -0700 (PDT)
Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF1311E80ED for <oauth@ietf.org>; Thu, 22 Aug 2013 10:34:26 -0700 (PDT)
Received: from mail-ob0-f174.google.com ([209.85.214.174]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKUhZLorJLpTtxvY4uIOYx99KjSESPlZwy@postini.com; Thu, 22 Aug 2013 10:34:27 PDT
Received: by mail-ob0-f174.google.com with SMTP id wd6so4179207obb.19 for <oauth@ietf.org>; Thu, 22 Aug 2013 10:34:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QTlONJ1QQPKQUgv8zELsgk6RACAfjCJu1u5W6OWEgAc=; b=b5nRd9/D4bJfWHX9ZUm5TOx+SoBc8rP5Ed/BJQHCnlWzypPZr1bzdjCr/CN+JXlsGf U1u1vAa9A7SfSQJAVlOaUtbCVOTLgzI+cOXDfaIsdXw6Z6+xJFRrBpdqNIlxFQ6JZxF8 eGKVDvytN6Xsx5I7OnndQqaUrytUfAoJn930Y/4kCmRZBPovMj2wh4UotLDQIgMn7MDm tdRJghUff34EGt5J71s8xe2MX+dmQ30CfbnR8HdVaiWfanLjdAVWePVJSPgWiBIuSGRN jyeUXVyLtnqhID8iqPmEgzzwklFneTP9g98llyiscjNz0K/p4S9eCmHy8dLbY2qDabyk mdWQ==
X-Gm-Message-State: ALoCoQmLXh6RRK1nemyrhzMjUS+jnTZD6Ej5ZlmgyFy4rqXyKFYNStP8onsj3StZoPx9L4D0XQZmCLezkLwU73MQf3CjDqJtWxZ+NES1zYLtHWlSTHvgNOD7A8lSkvfHY8mjvu5dmOEgJ3RdOA2mDun8X0YPNkIGIw==
X-Received: by 10.50.3.42 with SMTP id 10mr6823097igz.39.1377192865886; Thu, 22 Aug 2013 10:34:25 -0700 (PDT)
X-Received: by 10.50.3.42 with SMTP id 10mr6823087igz.39.1377192864775; Thu, 22 Aug 2013 10:34:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.183.133 with HTTP; Thu, 22 Aug 2013 10:33:54 -0700 (PDT)
In-Reply-To: <520FBDAC.9080404@lodderstedt.net>
References: <e1cdc1b2a4d1841d12938a900355121f@lodderstedt-online.de> <706472E2-DF7D-4963-8C07-552F3690D927@ve7jtb.com> <CA+k3eCR+0MCLC5F5ZtAt28vcn0mCfM9kHOHcc2nO4BQY3vt73A@mail.gmail.com> <520FBDAC.9080404@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 22 Aug 2013 11:33:54 -0600
Message-ID: <CA+k3eCQNE5ScN0ebvoiS+GSpCie8L1486P45SeUVSJbVShFd0Q@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary="089e013c6a727e167804e48cb335"
Cc: oauth <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, 22 Aug 2013 17:34:32 -0000
I so believe that was the intent and what it probably should have said. So maybe errata makes sense? On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt" <torsten@lodderstedt.net> wrote: > Hi all, > > would it make sense to issue an errata and add a "public" to the sentence > as follows? > > "A _public_ client MAY use the "client_id" request parameter to identify > itself > when sending requests to the token endpoint." > > regards, > Torsten. > > Am 01.08.2013 15:57, schrieb Brian Campbell: > > 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 >> >> > >
- [OAUTH-WG] Authz Header + client_id in message bo… Torsten Lodderstedt
- Re: [OAUTH-WG] Authz Header + client_id in messag… John Bradley
- Re: [OAUTH-WG] Authz Header + client_id in messag… Brian Campbell
- Re: [OAUTH-WG] Authz Header + client_id in messag… Torsten Lodderstedt
- Re: [OAUTH-WG] Authz Header + client_id in messag… Brian Campbell
- Re: [OAUTH-WG] Authz Header + client_id in messag… Justin Richer
- Re: [OAUTH-WG] Authz Header + client_id in messag… John Bradley