Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
Dario Teixeira <dario.teixeira@nleyten.com> Fri, 27 January 2017 11:25 UTC
Return-Path: <dario.teixeira@nleyten.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 8413B1294AD for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 03:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 j6vDqpImdUqA for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 03:25:36 -0800 (PST)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928E51294AA for <oauth@ietf.org>; Fri, 27 Jan 2017 03:25:36 -0800 (PST)
Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1248A172125; Fri, 27 Jan 2017 12:25:35 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id S6I0a9QcinCf; Fri, 27 Jan 2017 12:25:33 +0100 (CET)
X-Originating-IP: 10.58.1.149
Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPA id 29F75172134; Fri, 27 Jan 2017 12:25:32 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Jan 2017 11:25:32 +0000
From: Dario Teixeira <dario.teixeira@nleyten.com>
To: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAANoGh+YdPhvpNfPcWcQVKF1iO+jdrtPMVRRiTp2+GUq2LCD4A@mail.gmail.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>
Message-ID: <b9d02304725cc8e646cb68b682809328@nleyten.com>
X-Sender: dario.teixeira@nleyten.com
User-Agent: Roundcube Webmail/1.1.2
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/FtO6qwUpNLkTgZemVTlusQ1C-K8>
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: Fri, 27 Jan 2017 11:25:38 -0000
Hi, > Justin and I are recommending different approaches. Thanks for the clarification. To make sure there's no further confusion, allow me to define the various parties involved in the exchange: * Native App (NA): the native application running on the user's phone. This application is written by me. * Resource Server (RS): the server application that the NA wishes to communicate with. This application is also written by me, and offers a RESTful API to the NA. * OpenID Provider (OP): a 3rd party organization like Google that is able to authenticate users. * Authorization Endpoint (AE): a server run by the OP. * Token Endpoint (TE): another server run by the OP. * User Agent (UA): a browser running on the user's phone. > 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. To make sure I understood it correctly, here are the steps involved in Justin's scheme: 1. The NA asks the UA to show a webpage with links such as "Login with Google" or "Login with Facebook". Clicking on those links executes a request to the AE of the corresponding OP. The 'redirect_uri' parameter of the request points to the NA. 2. The user clicks on one of the links shown in the UA. 3. The AE sends the NA an Authorization Code. 4. The NA executes a request to the TE of the OP, sending it the Authorization Code obtained in step 3. The 'redirect_uri' parameter of the request points to the NA. 5. The TE sends the NA an ID token. 6. The NA sends the RS this ID token. 7. The RS validates the ID token by checking its signature against a hardcoded list of OP public keys. If valid, it sends back to the NA a cookie that can be used in future requests. It's pretty straightforward, but there's a bunch of corner cases surrounding expiration of tokens and making sure the list of OP public keys are synchronised. > 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. Again, please allow me to describe the various steps involved in the AppAuth scheme, to make sure we're on the same page: 1. The NA executes a request to the RS, telling it the user wishes to login. It also sends the RS a secret S to be used later. 2. The RS replies with a webpage with links such as "Login with Google" or "Login with Facebook". The 'redirect_uri' present on those links points towards the RS. 3. The NA asks the UA to show the webpage it received in step 2. 4. The user clicks on one of the links shown in the UA. 5. The AE sends the RS an Authorization Code. 6. The RS executes a request to the TE of the OP, sending it the Authorization Code obtained in step 5. The 'redirect_uri' parameter of the request points to the RS. 7. The TE sends the RS an ID token. 8. The RS validates the ID token by checking its signature against a hardcoded list of OP public keys. It now knows that any future requests from the NA with secret S are authentic. There's an obvious problem with this scheme: there's no way for the NA to know when and if the authentication was successful. Did I miss something, or is this a know problem with the AppAuth scheme? Thanks again for your attention! Best regards, Dario Teixeira
- [OAUTH-WG] OAuth2/OIDC for client-server mobile a… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Justin Richer
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Phil Hunt
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… ve7jtb
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Brian Campbell
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… ve7jtb
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… John Bradley
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… John Bradley
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… John Bradley
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Dario Teixeira
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… ve7jtb
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth2/OIDC for client-server mobi… ve7jtb