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

Dario Teixeira <dario.teixeira@nleyten.com> Fri, 27 January 2017 17:16 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 CD13512944D for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 09:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.756
X-Spam-Level:
X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156] 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 cXLklfdlDnYA for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 09:16:28 -0800 (PST)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF9E129411 for <oauth@ietf.org>; Fri, 27 Jan 2017 09:16:28 -0800 (PST)
Received: from mfilter5-d.gandi.net (mfilter5-d.gandi.net [217.70.178.132]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 9F18E41C091; Fri, 27 Jan 2017 18:16:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter5-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter5-d.gandi.net (mfilter5-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id LFM89nLIo5fp; Fri, 27 Jan 2017 18:16:25 +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 relay5-d.mail.gandi.net (Postfix) with ESMTPA id 1A3EA41C080; Fri, 27 Jan 2017 18:16:24 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Jan 2017 17:16:24 +0000
From: Dario Teixeira <dario.teixeira@nleyten.com>
To: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAANoGhJ0ojaEV8FNvtuOhyRMMeX6rp3sieyvqdRhoU-EDo3hFw@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> <b9d02304725cc8e646cb68b682809328@nleyten.com> <CAANoGhJ0ojaEV8FNvtuOhyRMMeX6rp3sieyvqdRhoU-EDo3hFw@mail.gmail.com>
Message-ID: <d5385881b1aeb7d87146cc2b22027799@nleyten.com>
X-Sender: dario.teixeira@nleyten.com
User-Agent: Roundcube Webmail/1.1.2
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LMOkUKnB-s3ztnaZVuAriTQsgpk>
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 17:16:31 -0000

Hi,

Thanks for your reply and your patience!

> Our recommendations are based on the assumption that the end state
> is your app having an access token for your rest API.
> If that is not what you are trying to do then we may be talking at
> cross purposes.

Yes, that is exactly the end state I'm looking for, though there
is a chance there is some misunderstanding about the whole picture.
Allow me to summarise the current situation:

Users interact with a Native App (NA) running on a mobile phone.
This app talks with a Resource Server (RS) via a RESTful API.
Because there is private user data on the RS, the very first
interaction between the NA and the RS is a login where the NA asks
the user for an email+password combination, which it then sends
to the RS.  If the email+password combination is valid, the RS
replies with an access token that must be used by the NA in all
its future requests.

This works fine, but has the disadvantage of requiring users to
manually enter their email and password. The user experience would
be much improved if users had the option to login using their Google,
Facebook, or Github account.

Now, it is my understanding that OpenID Connect is the technology
used nowadays to provide this sort of Single Sign-On.  All I'm
looking for is documentation on how OIDC is actually implemented
in this scenario.

Best regards,
Dario Teixeira