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

<ve7jtb@ve7jtb.com> Sat, 28 January 2017 01:23 UTC

Return-Path: <ve7jtb@ve7jtb.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 87322129B5E for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 17:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
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 2CX0JSG4BZ6M for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 17:23:13 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27C3129B5D for <oauth@ietf.org>; Fri, 27 Jan 2017 17:23:12 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id 194so85331859pgd.2 for <oauth@ietf.org>; Fri, 27 Jan 2017 17:23:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=0LKSNQtuWwtgQvrPbRS5zk7SiFKvEy4/cJb3mf4+CbA=; b=oV30UTrWq35lwrGJiXFfjMh54m8myG7cXRetltcCEEgxz3uE1g9xOCLTzycjoBHaB+ E9c04STS4BBoKblM/KsUzz6XfTd0m6QgYENUOW/8MjaSO5Ij2RgzWAJ4ncpBzPQjj4DM PChYlm6N+PVkI/Uoa5az9Vj1W1iVLCthEHI/VOP9nb06Yd72ZMNgQSHA9AlMgdZVY7by zZOXsXTUxvMYTy9fWRRa4YW5eVZ2yawTLsrjq1ajEqq8J+WJ4lwopasT4pEONCt+znvg 9iYZka/esklCr88zTfFf9nU4jc8Bgn8G7Bjslek5EKmQJ/O8lVvVpWHoIhv2xnIS3bcK xCRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=0LKSNQtuWwtgQvrPbRS5zk7SiFKvEy4/cJb3mf4+CbA=; b=uGqZPN6K0wUyk7718rRVK9CK5OB7bCUWDqDxBzPjfwm9C6z6IJhpm+Qm+1RcKVXP6n n744gnySINnGznntINUtRIH4qUN+TWQtcOQatgVo1cg7FCGWi0CEEl7TluDtLFATIogK wKzFIBau1KHjY2O+uV3NYXBJnrxZDaq0yErF+bXXtleTBekjR0vlOn2c+kd2P8rSlR6D rw7j00kgNdhcwIfQQqySOtffRjbAVZhRW88YYbBrtcxjFRFh2Vg/7emFuGO329wqgNs5 QyehtyATMvirOlW5DoG6oozZYmwtrFmXbZYyMOmy39LJzaPvqSUqpcqObRDEssSxnWl5 IhJA==
X-Gm-Message-State: AIkVDXItn32dL9nZgTUx24ZTYPX5X9TdmVASRuHvqlm+I/sb8MzYr1mo6VmTbiBUPYiGiQ6X
X-Received: by 10.99.248.17 with SMTP id n17mr12431721pgh.17.1485566592347; Fri, 27 Jan 2017 17:23:12 -0800 (PST)
Received: from ?IPv6:2001:569:7128:2400:dd34:490f:5338:686d? (node-1w7jr9qhemnddm7lx0d20ehkd.ipv6.telus.net. [2001:569:7128:2400:dd34:490f:5338:686d]) by smtp.gmail.com with ESMTPSA id k184sm14096480pgc.23.2017.01.27.17.23.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 17:23:10 -0800 (PST)
Message-ID: <588bf27e.c16f630a.5cac3.9bb1@mx.google.com>
MIME-Version: 1.0
To: Dario Teixeira <dario.teixeira@nleyten.com>
From: ve7jtb@ve7jtb.com
Date: Fri, 27 Jan 2017 17:23:02 -0800
Importance: normal
X-Priority: 3
In-Reply-To: <d5385881b1aeb7d87146cc2b22027799@nleyten.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> <d5385881b1aeb7d87146cc2b22027799@nleyten.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a114c68700ad02d05471d6d8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hxnIFbXDiqXCqAWMlQ05gQkXhtc>
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: Sat, 28 Jan 2017 01:23:14 -0000

It sounds like you are currently doing something like the OAuth resource owner flow.

Is there a Authorization server currently associated with your resource server?

If so you can change the OAuth flow you are using to the code one as described in App Auth.

You still need to authenticate the users at your server using the current  username and password or via OpenID Connect to Google.

This is a two step process.  If you try to combine them by trying to make your NA the connect client you may save a step in the short term but will regret it in the long term when you decide to add another identity provider like Microsoft etc.


OAuth from the NA to your server to authorize the native app, and your server to Google via Connect to Authenticate the user.

Regards
John B.




Sent from Mail for Windows 10

From: Dario Teixeira
Sent: January 27, 2017 9:16 AM
To: John Bradley
Cc: Phil Hunt; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

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