Return-Path: 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 75A96129664 for ; Fri, 17 Feb 2017 09:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 PBqFDziAJr04 for ; Fri, 17 Feb 2017 09:43:16 -0800 (PST) Received: from mx0b-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (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 B3271129655 for ; Fri, 17 Feb 2017 09:43:16 -0800 (PST) Received: from pps.filterd (m0074409.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1HHfJxh015857 for ; Fri, 17 Feb 2017 11:43:16 -0600 Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by mx0a-0019e102.pphosted.com with ESMTP id 28p3t28d2x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 17 Feb 2017 11:43:16 -0600 Received: by mail-oi0-f69.google.com with SMTP id u143so56295859oif.1 for ; Fri, 17 Feb 2017 09:43:15 -0800 (PST) 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=VuNDckd2hmt4X1E267XA272kMrq0EhSN6TbVFVQziaM=; b=bmmJADFHiGTEJp6bsKrK93IBR94qKqIumvBQ2JkQxwgwSEtOrsGKcwm0fZNHaSAFDs RQai6RXOxdrYPTE1uKGflnBmZGx2c/OQHMsP9LChxNELA82YG8aL9DDn5zL8dowNEdjS Xjq1An12Hydyd/0CXgt9J/Sv/JBKKck8nb116RnZQsmeIj3EcYix4MvKE5vOTmlGYGE3 n+BoxYujVRdygL9VBjbv3HBvOb7Vey6SbNoNZq6xoe6clhsLCmXZntTikkHJN6RAwF8O RTG06guJT5wgCBLOVjqfA92a1vJW9v455xInDwh9aV+hyou/RcnAybCpX/WyHR3JiXwl lp0w== X-Gm-Message-State: AMke39lootK+4ixzSexUlyq6yO/h1nLTP570o6oeM+riclZjbp8SD1bYvo+hra5sgfDjYK6E16hCwp4LkctBur8QyoMDzEadS7Kg+Uh+ag80sKvHb68A0aQDTBjwNeNePL4hk0vs1uEG0f4E X-Received: by 10.157.29.182 with SMTP id y51mr4514879otd.256.1487353395181; Fri, 17 Feb 2017 09:43:15 -0800 (PST) X-Received: by 10.157.29.182 with SMTP id y51mr4514875otd.256.1487353394998; Fri, 17 Feb 2017 09:43:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.85.85 with HTTP; Fri, 17 Feb 2017 09:42:54 -0800 (PST) In-Reply-To: <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com> References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com> <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com> From: Adam Lewis Date: Fri, 17 Feb 2017 11:42:54 -0600 Message-ID: To: Jim Manico Content-Type: multipart/alternative; boundary=001a1141fb8ac3c7540548bd728e X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702170164 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:43:20 -0000 --001a1141fb8ac3c7540548bd728e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1000 We are currently going through internal turmoil over the usage of implicit grant for ua-based apps. The webapp case is well understood and the WG has work in progress to define best practices for native apps. Having one for ua-based apps would be HUGELY beneficial On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico wrote: > Thank you to those answering my question on implicit for JS clients. > > The responses so far seem to represent what the security world is saying > about the implicit grant - keep away from it other than for a few OIDC us= e > cases. > > Does anyone think it would be valuable to author a brief RFC to give clea= r > OAuth 2 recommendations for JavaScript client developers? > > I mean - the OAuth 2 body of work just needs a few more RFC's, right? :) > > Aloha, Jim > > > > On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de wrote: > > Same for Deutsche Telekom. Our javascript clients also use code flow with > CORS processing and of course redirect_uri validation. > > > > Best regards > > > > Sebastian > > > > *Von:* OAuth [mailto:oauth-bounces@ietf.org ] *Im > Auftrag von *Bill Burke > *Gesendet:* Freitag, 17. Februar 2017 00:14 > *An:* oauth@ietf.org > *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow > > > > For our IDP [1], our javascript library uses the auth code flow, but > requires a public client, redirect_uri validation, and also does CORS > checks and processing. We did not like Implicit Flow because > > 1) access tokens would be in the browser history > > 2) short lived access tokens (seconds or minutes) would require a browser > redirect > > I'd be really curious to hear other's thoughts though. > > [1] http://keycloak.org > > > > > > > > > On 2/16/17 5:44 PM, Jim Manico wrote: > > Hello Folks, > > I noticed that Google supports the OAuth 2 Implicit flow for third-party > JavaScript applications. > > https://developers.google.com/identity/protocols/OAuth2UserAgent > > > Isn't this generally discouraged from a security POV? *Is there a better > OAuth 2 flow for third party SPA applications?* > > Aloha, > > -- > > Jim Manico > > Manicode Security > > https://www.manicode.com > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > Jim Manico > Manicode Securityhttps://www.manicode.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1141fb8ac3c7540548bd728e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1000

We are currently going through in= ternal turmoil over the usage of implicit grant for ua-based apps.=C2=A0 Th= e webapp case is well understood and the WG has work in progress to define = best practices for native apps.=C2=A0 Having one for ua-based apps would be= HUGELY beneficial



On Fri, Feb 17, 2017 at 11:40 AM= , Jim Manico <jim@manicode.com> wrote:
=20 =20 =20

Thank you to those answering my question on implicit for JS clients.

The responses so far seem to represent what the security world is saying=C2=A0 about the implicit grant - keep away from it other than for a few OIDC use cases.

Does anyone think it would be valuable to author a brief RFC to give clear OAuth 2 recommendations for JavaScript client developers?

I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)

Aloha, Jim



On 2/17/17 6:03 AM, Sebastian.Ebling@teleko= m.de wrote:
=20 =20 =20

Same for Deutsche Telekom. Our javascript c= lients also use code flow with CORS processing and of course redirect_uri validation.

=C2=A0

Be= st regards

=C2=A0

Se= bastian

=C2=A0

Von: OAuth [mailto:oauth-b= ounces@ietf.org] Im Auftrag von Bill Burke
Gesendet: Freitag, 17. Februar 2017 00:14
An: oauth@ietf.org<= /a>
Betreff: Re: [OAUTH-WG] Google's use of Implicit Grant Flow

=C2=A0

For our IDP [1], our javascript library uses the auth code flow, but requires a public client, redirect_uri validation, and also does CORS checks and processing.=C2=A0 We did not like Implicit Flow because

1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a browser redirect

I'd be really curious to hear other's thoughts though.

[1] http://keycloak.org

=C2=A0

=C2=A0

=C2=A0

On 2/16/17 5:44 PM, Jim Manico wrote:

Hello Folks,

I noticed that Google supports the OAuth 2 Implicit flow for third-party JavaScript applications.

https://d= evelopers.google.com/identity/protocols/OAuth2UserAgent

Isn't this generally discouraged from a security POV? I= s there a better OAuth 2 flow for third party SPA applications?

Aloha,

-- 
Jim Manico
Manicode Security
https://www.manicode.com
          


            

            

            

          
_______________________________________________<=
u>

          
OAuth mailing list

          
OAuth@ie=
tf.org

          
https://www.ietf.org/mailman=
/listinfo/oauth

=C2=A0



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--=20
Jim Manico
Manicode Security
https://w=
ww.manicode.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a1141fb8ac3c7540548bd728e--