IETF Logo Mail Archive

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Phil Hunt <phil.hunt@oracle.com> Sun, 09 December 2018 16:53 UTC

Return-Path: <phil.hunt@oracle.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 EA30C126BED for <oauth@ietfa.amsl.com>; Sun, 9 Dec 2018 08:53:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.76
X-Spam-Level:
X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 Duj_jnKGl6VR for <oauth@ietfa.amsl.com>; Sun, 9 Dec 2018 08:53:13 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 34F3B124D68 for <oauth@ietf.org>; Sun, 9 Dec 2018 08:53:12 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB9Gi8JX174245; Sun, 9 Dec 2018 16:53:10 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=DG5AmI+gZZXH22u2uXcN1zTaa1I8QdHpubpJD4Kc8ew=; b=tWhi6X3W2+FZ1mogAYNfPymgTJhhiM+UWKB9WDTxHTwHhTlEPKuvDV1l+vzT0YBe9wws Bzs19Co74kJJJUIkd2Rg921lKhIG00OAk6UevjLVyEHg+V2XeRQ41ecNMfqkE5vJJn3E H/l7wkcgvAxdNh/03E5tCtajJOR9G/m+CNrJkZ5CWHRwlLIzeNP8zpylD6ARcJZxWqkK DokKppuv4HJ4odhagScJLr9fOjOSMF/Z7NkFZhlbp62OC2iScS7G7JO9/Low0+E3ftNw exl5zYv462yYsTWO8kvSbx7+Dy2FBUY3Pdk8OwgvQeg/NO+09qjHAz9rNjBWuOAAWIvD TQ==
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2p86kqjqwe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 09 Dec 2018 16:53:10 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wB9Gr9hu004748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 9 Dec 2018 16:53:09 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB9Gr9Hb023444; Sun, 9 Dec 2018 16:53:09 GMT
Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 09 Dec 2018 08:53:08 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail-21F35BE9-0CFF-4651-9D25-A870A61470BA"
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <d6d4ecf5-39ea-489c-8024-87c760a9ec23@getmailbird.com>
Date: Sun, 09 Dec 2018 08:53:03 -0800
Cc: David Waite <david@alkaline-solutions.com>, oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <FA70DCCA-CCDB-49D1-B478-1A7B5EC31B40@oracle.com>
References: <VI1PR0801MB211266BA6F6E06FFB3081425FAD80@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAD9ie-v3onmKc498cg_-a0AD58ZV=aZANtz=UV+Q0f=9N3nSzQ@mail.gmail.com> <OSBPR01MB2869E83F37046C7FCD4463DDF9D10@OSBPR01MB2869.jpnprd01.prod.outlook.com> <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <OSBPR01MB28690F77DFFB2A85BDB83FBAF9D10@OSBPR01MB2869.jpnprd01.prod.outlook.com> <D6C66E6A-687B-4997-B830-980BE25994C2@lodderstedt.net> <CAANoGhL9aD75AV9QQRdeGE1=4ynjTnULNVr0PXXvt20ipsb4Rw@mail.gmail.com> <FE51CE20-7A49-4A13-A180-6A7C481F3965@lodderstedt.net> <CAGBSGjrzeeR5QQ=nA=gTj0q7sRvRVc0DDacbxB+ED87ymHSOuA@mail.gmail.com> <VI1PR0801MB21120AA6CC9437E237F481A2FAAC0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <EA38C666-2325-430A-91B0-C02AAC65FCC8@lodderstedt.net> <CAO_FVe7j_79sPrRSFXvQJax3vDjT_0=ZaWHW9aan9rJnLUftkA@mail.gmail.com> <CAO7Ng+vsQ2i4=V0nq+ymO6aNCvurb02+Zt7HHwp4=FnWCO4pUQ@mail.gmail.com> <CAANoGhLx42Noqw4WN-THXbGYvS3t1Z2_EmPs+z641-cNovFNvw@mail.gmail.com> <CAANoGh+1w! !Rzz5x7jJrMy-KzCpeK0KN3fK2Qo62KEhz+9SE83=g@mail.gmail.com> <CA+k3eCRjET6gJjX+G7pq-kwFUDgppTK-mrXCAgMtYtW+gVrCbw@mail.gmail.com> <CAD9ie-t=wM6D_zwz0kuPkR19xGfFwfYP=0vjX8uGd4oKsukAOg@mail.gmail.com> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <FAFC4820-982B-49B9-9CC5-AFD5CFC4CA3B@lodderstedt.net> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <CAO_FVe4HrnnQb5-shvgeSAGa+XVKhHtXPsDT_TPezu4Y-CaD=A@mail.gmail.com> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <CAO_FVe7_CsqkTCRSPK5iT5dH5w_NmDuZ-g-2UJgHefUP2i3beQ@mail.gmail.com> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <CAO_FVe7QhqZEcqeSurPU5QxTN3Z1Lp9zY6XpVQxk1VdCGLMUhA@mail.gmail.com> <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> <8A2BC516-69AA-4CDB-A31E-5AF59FBA9CF0@oracle.com>! <d6d4ecf5-39ea-489c-8024-87c760a9ec23@getmailbird.com>
To: Brock Allen <brockallen@gmail.com>
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9102 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=862 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812090155
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/MlS3JP7A_zWt_Cq_QY1N3OCHfy0>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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: Sun, 09 Dec 2018 16:53:15 -0000

Yes. This was my worry. 

Unless the oauth server is also an OIDC OP, it has no notion the user login state. That state is held in cookies belonging to a federated provider. 

The notion that javascript acting as a client and depends to the user login state is what sets these cases apart.  We have to be able to co-ordinate between resource api, AS authorization which builds off of some form of federation/sso. 

Phil

> On Dec 8, 2018, at 6:51 PM, Brock Allen <brockallen@gmail.com> wrote:
> 
> > How would the token endpoint detect login status of the user?
> 
> Oddball idea: why not use the cookie? If the assumption is that the RT is being used from a client-side browser-based app, and CORS allows for credentials, then perhaps this is a way to bind the RT to the user's browser session. The spec does say that alternative credentials are allowed at the token endpoint...
> 
> Sounds icky, but compared to iframes back to the authorize endpoint?
> 
> -Brock
>

v2.23.0 | Report a Bug | By Email