IETF Logo Mail Archive

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

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Thu, 26 January 2017 17:50 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 0BB841298BA for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2017 09:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.555
X-Spam-Level:
X-Spam-Status: No, score=-8.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, 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 x86mqKvv8qj9 for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2017 09:50:31 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 7BA2E12989E for <oauth@ietf.org>; Thu, 26 Jan 2017 09:50:31 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0QHoTaR017151 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2017 17:50:30 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v0QHoTt5001276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2017 17:50:29 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0QHoReH029488; Thu, 26 Jan 2017 17:50:27 GMT
Received: from [10.0.53.148] (/209.53.70.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jan 2017 09:50:27 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (14C92)
In-Reply-To: <be34721f2dbd38434edadcef5658131a@nleyten.com>
Date: Thu, 26 Jan 2017 09:50:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE7691D1-C80A-46F7-ACC0-4E065A815B88@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>
To: Dario Teixeira <dario.teixeira@nleyten.com>
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iFa3f_C9SL-igwQ0FA2UetEtbuQ>
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 17:50:33 -0000

Afaik, the client app ends up with an access token (at). It never has to deal with id tokens. That all happens by way of the oauth AS server calling oidc itself.  Iow the oauth as is the oidc client.  

The code in the mobile client is trivial by comparison and does not need to do id token validation.

Phil

> On Jan 26, 2017, at 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
>

v2.23.0 | Report a Bug | By Email