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

<ve7jtb@ve7jtb.com> Sat, 28 January 2017 02:16 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 80F23129434 for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 18:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, URIBL_BLOCKED=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 Q9TpDy8kqc-P for <oauth@ietfa.amsl.com>; Fri, 27 Jan 2017 18:16:21 -0800 (PST)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 98D5E129426 for <oauth@ietf.org>; Fri, 27 Jan 2017 18:16:21 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id 3so26987904pgj.3 for <oauth@ietf.org>; Fri, 27 Jan 2017 18:16:21 -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=PK9vqiyFi0AunBi9rQrzONlyomZFchyCxhRpGW7Cd6g=; b=I/Zwj5QYr2uxEIGaKNGGtv2LCeH1SbzGeuPFN2LuVk6JcLRTegDe/w2d2GEKg8rch5 5BIgF+gFDkN02QJzerpp6zpsSuPA0EIgNGGQGna7FKMEQBUrH18xkDy7dmP51OLXmytD McFdP+3t6M0cEb+AS5ZJkrAebybJpoKsTEYbbWouTgnmk3vc9YaveRtHeRwxoLsQtEMt OgdtbolZJt/DHZTo+WMBlHJrBkDrcd+HZQDm4ZDqwnhPyPLjE/+Bo2mH8tw+NimIgPEH 0Fp3m1UX+Ja4B13Vq+oxO6f4gFQCWEzDMbm/sia9NLtVtVT3jcrBkfM67hvz3qhqkAIq LVbQ==
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=PK9vqiyFi0AunBi9rQrzONlyomZFchyCxhRpGW7Cd6g=; b=sNvVGYRVoWoYPTyySXqxpzhNXqL4Fpj78Ptvd/3JquFxWWnoPHUUN/U/hQJhd9SOou EvWS8FkSxch6pnv70Tvs9EDH0b6b/S0M2h8MsL/Ru4gRCl7M5E8uRACJrU2AkVJeU92x MuclnZtTS8ahLOTUoZ4a0+OsS3DdG4DqzCaRh1xl/xPhr+z6Mu2QJ4Yt2t5sCNGxDpVz YLdYWgGO2NsOy5fquLi4x4zJf+cQIqpC/1BIvlAM7NmLlLfXPm7Bb4Cq289sjtMHt50p kaW9G8sHbSAhefAivuaIHrxufEfY/jyTT+3UF9YHcV6stRX0+voMxLZ62460IATIGXp2 qKPA==
X-Gm-Message-State: AIkVDXI1rvpgtPazk36EwiOmtwvs0JHKT7wSEYaPIXfl+CZ+cX+I1ueRxj1q095hbrqMwd+w
X-Received: by 10.84.198.164 with SMTP id p33mr16802952pld.156.1485569781059; Fri, 27 Jan 2017 18:16:21 -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 64sm14200837pfz.48.2017.01.27.18.16.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 18:16:19 -0800 (PST)
Message-ID: <588bfef3.4319620a.b813.ac72@mx.google.com>
MIME-Version: 1.0
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
From: ve7jtb@ve7jtb.com
Date: Fri, 27 Jan 2017 18:16:19 -0800
Importance: normal
X-Priority: 3
In-Reply-To: <E0830F7E-7AD3-4DD8-87F3-663BF9F48BA1@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> <b9d02304725cc8e646cb68b682809328@nleyten.com> <CAANoGhJ0ojaEV8FNvtuOhyRMMeX6rp3sieyvqdRhoU-EDo3hFw@mail.gmail.com> <d5385881b1aeb7d87146cc2b22027799@nleyten.com> <588bf27e.c16f630a.5cac3.9bb1@mx.google.com> <E0830F7E-7AD3-4DD8-87F3-663BF9F48BA1@oracle.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="94eb2c18a3381a634805471e2b1e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3qp20YUemyeepJs3RPP9opeaUFc>
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 02:16:23 -0000

A mobile app that just used Google API only would/should register for a Google client Id and use connect with Google.

A mobile app that uses only its own API should have a client ID from its own authorization server, and leave it to the authorization server to deal with the authentication.

Where it gets more grey is when the native app wants to access both Google API directly and its own REST API.

In the simple AppAuth model you could have the App owners Resource server proxy the information from Google etc as it gets a google access token if the user authenticates to google via Connect.

I think that is the safest way to do it.

Justin’s recommendation is a bit more optimised for this scenario where the Native application wants to access two resource servers.   In that case with one client_id from Google it can get both a id_token and access token for Google.   It uses the acess token to get the plus friends list or something like that and sends the id_token to its backend to exchange for a cookie or some other form of access token assuming the Native apps authorization/resource server doing the exchange properly validates the signature and audience in the id_token.  

The original question was not about multiple RS and I don’t think that is really the most common case, so I didn’t go there in my answer as it adds more complexity to something that is complex enough.

John B.



Sent from Mail for Windows 10

From: Phil Hunt (IDM)
Sent: January 27, 2017 5:45 PM
To: ve7jtb@ve7jtb.com
Cc: Dario Teixeira; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

What is concerning is that many are using resource owner flow so the client app can capture the uid/password under the assumption that the client needs to control the branding experience much has been done in silo approaches of the past. 

Adding to the confusion I note that many of the cloud provider site docs do not clearly distinguish mobile apps from web apps. Mobile app developers arw reading docs and telling me that oracle, google, and azure require the mobile app to register for an openid client id. 

Near as I can tell it is confusion over the difference between authz and authN. 

Phil

On Jan 27, 2017, at 5:23 PM, ve7jtb@ve7jtb.com wrote:
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