Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Thu, 26 January 2017 18:24 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 ADF0A12996E for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2017 10:24:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.417
X-Spam-Level:
X-Spam-Status: No, score=-7.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, 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 vfHlCRzb8mY0 for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2017 10:24:14 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 30FD312996D for <oauth@ietf.org>; Thu, 26 Jan 2017 10:24:14 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0QIOBGm011652 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Jan 2017 18:24:12 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0QIOAAG030579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2017 18:24:11 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v0QIO840004065; Thu, 26 Jan 2017 18:24:09 GMT
Received: from [25.248.230.255] (/24.114.40.83) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jan 2017 10:24:08 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail-DEA8BFE6-5808-4077-9AEA-108ADC754E69"
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (14C92)
In-Reply-To: <CAANoGh+YdPhvpNfPcWcQVKF1iO+jdrtPMVRRiTp2+GUq2LCD4A@mail.gmail.com>
Date: Thu, 26 Jan 2017 10:24:04 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <CD648665-652A-45CB-81B2-7C7B4ED26FDD@oracle.com>
References: <ffc794a133b4b5fb341a0590c6848034@nleyten.com> <5889010c.06d0620a.31d79.5dd8@mx.google.com> <CA+k3eCQ69_+7JEZN30OpOwfW-cy1Dmu6-K84geLLvrjWxpt=7A@mail.gmail.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> <CAANoGhKON-a22CjHTGe3AsSGR=epFZ_YLpKSt9DzrcZ1fY6mPA@mail.gmail.com> <be34721f2dbd38434edadcef5658131a@nleyten.com> <CAANoGh+YdPhvpNfPcWcQVKF1iO+jdrtPMVRRiTp2+GUq2LCD4A@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_bGSaHtcMHv_zDAa9o9BOMv-IPY>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 26 Jan 2017 18:24:16 -0000

An seeing bad impls with justins pattern. In particular aud is not checked. 

The idp has to know the rsrc aud or the as has to know the client id the mobile app is using with OP provider. It ends up being complex with room for mistakes. 

Phil

> On Jan 26, 2017, at 10:00 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> Justin and I are recommending different approaches.  
> 
> My recommendation is that your app do appAuth to your server to get a access token for your API.   Your server performs openid connect to google, SAML to salesForce or Facebook Connect to Facebook and manages verification keys.   If the user is authenticated by the IdP it then authorizes your app on the device to access your API.  
> 
> Justin is recommending that you build a client/relying party for each IdP into your native app and pass the results of authentication ID_token, Facebook signed request etc to your back end server for it to verify and issue some cookie or webkey (probably not OAuth token) to your App for accessing your API.  
> 
> My recommendation allowed you to protect your API using OAuth and to add or modify IdP for your users without redeploying your native app.
> 
> Justin's approach avoids you needing to run a OAuth authorization server.   ( He has a great open source one you could use).  
> 
> I think it is a style diffrence.  I think separating authorization and authentication into two steps is cleaner and easier to maintain over the long term.  
> 
> John B.  
> 
>> On Jan 26, 2017 8:51 AM, "Dario Teixeira" <dario.teixeira@nleyten.com> wrote:
>> Hi,
>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]
>>> 
>>> They are OpenID foundation library's not Google's.   Google, Ping and
>>> a number of others are active contributors if you look at the git
>>> repositories.
>> 
>> Thanks for the link.  Perhaps I'm missing something, but the AppAuth
>> pattern as described by this document represents only half the picture:
>> at the end of the interaction, the native app is in possession of a
>> token that authenticates the user.  However, my server cannot accept
>> that token blindly!
>> 
>> Now, the way I would solve this is by keeping a hard-coded list of
>> OpenID Provider public keys on my server, which I would use to
>> verify that the token was indeed signed by the OIP.  Correct me
>> if I'm wrong, but this also seems to be the recommended approach,
>> right?
>> 
>> Thanks again for your time!
>> Best regards,
>> Dario Teixeira
>>