[OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body
Tom Van Oppens <Tom.Van.Oppens@be.ibm.com> Wed, 24 January 2018 10:19 UTC
Return-Path: <Tom.Van.Oppens@be.ibm.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 AA57112DA07 for <oauth@ietfa.amsl.com>; Wed, 24 Jan 2018 02:19:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 NZm6v-S53paw for <oauth@ietfa.amsl.com>; Wed, 24 Jan 2018 02:19:39 -0800 (PST)
Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8232F12D957 for <oauth@ietf.org>; Wed, 24 Jan 2018 02:19:39 -0800 (PST)
Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0OAJ9xB147200 for <oauth@ietf.org>; Wed, 24 Jan 2018 05:19:38 -0500
Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.75]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fpm6ghbqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <oauth@ietf.org>; Wed, 24 Jan 2018 05:19:37 -0500
Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for <oauth@ietf.org> from <Tom.Van.Oppens@be.ibm.com>; Wed, 24 Jan 2018 10:19:37 -0000
Received: from us1a3-smtp07.a3.dal06.isc4sb.com (10.146.103.14) by smtp.notes.na.collabserv.com (10.106.227.123) with smtp.notes.na.collabserv.com ESMTP; Wed, 24 Jan 2018 10:19:33 -0000
Received: from us1a3-mail10.a3.dal06.isc4sb.com ([10.146.77.204]) by us1a3-smtp07.a3.dal06.isc4sb.com with ESMTP id 2018012410193292-293153 ; Wed, 24 Jan 2018 10:19:32 +0000
X-Disclaimed: 35182
To: oauth@ietf.org
MIME-Version: 1.0
X-KeepSent: C97C8467:B35570A3-8025821F:00389998; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP7 Octobe4, 2013
From: Tom Van Oppens <Tom.Van.Oppens@be.ibm.com>
Date: Wed, 24 Jan 2018 10:19:33 +0000
X-LLNOutbound: False
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="=_alternative 0038B8548025821F_="
x-cbid: 18012410-3815-0000-0000-000004BCE43C
X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.455134; ST=0; TS=0; UL=0; ISC=; MB=0.260684
X-IBM-SpamModules-Versions: BY=3.00008419; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000247; SDB=6.00979612; UDB=6.00496535; IPR=6.00758917; BA=6.00005793; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019179; XFM=3.00000015; UTC=2018-01-24 10:19:35
X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused
X-IBM-AV-VERSION: SAVI=2018-01-24 07:27:38 - 6.00007954
x-cbparentid: 18012410-3816-0000-0000-0000AEBB0F0B
Message-Id: <OFC97C8467.B35570A3-ON8025821F.00389998-8025821F.0038B8AA@notes.na.collabserv.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_05:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OPFwxoO0U1ogYtOA54XwEaali6w>
Subject: [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: Wed, 24 Jan 2018 10:19:42 -0000
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-WG] rfc6749 question about the optional us… Tom Van Oppens
- Re: [OAUTH-WG] rfc6749 question about the optiona… Brian Campbell
- Re: [OAUTH-WG] rfc6749 question about the optiona… Nat Sakimura
- Re: [OAUTH-WG] rfc6749 question about the optiona… Tom Van Oppens
- Re: [OAUTH-WG] rfc6749 question about the optiona… Brian Campbell
- Re: [OAUTH-WG] rfc6749 question about the optiona… Mike Jones
- Re: [OAUTH-WG] rfc6749 question about the optiona… Brian Campbell
- Re: [OAUTH-WG] rfc6749 question about the optiona… Mike Jones