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

Justin Richer <jricher@mit.edu> Wed, 25 January 2017 18:26 UTC

Return-Path: <jricher@mit.edu>
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 B9A6B129AC8 for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2017 10:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.419
X-Spam-Level:
X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mhewJX__Y7AL for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2017 10:26:46 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 28F82129AC9 for <oauth@ietf.org>; Wed, 25 Jan 2017 10:26:46 -0800 (PST)
X-AuditID: 12074422-29fff70000005b19-3d-5888ede569c3
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 04.D9.23321.5EDE8885; Wed, 25 Jan 2017 13:26:45 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v0PIQihP026638; Wed, 25 Jan 2017 13:26:44 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v0PIQgHX006704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Jan 2017 13:26:44 -0500
To: Dario Teixeira <dario.teixeira@nleyten.com>, oauth@ietf.org
References: <ffc794a133b4b5fb341a0590c6848034@nleyten.com>
From: Justin Richer <jricher@mit.edu>
Message-ID: <2fc78923-95a7-7def-3d59-65231f43ad0b@mit.edu>
Date: Wed, 25 Jan 2017 13:26:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <ffc794a133b4b5fb341a0590c6848034@nleyten.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrvv0bUeEwd5vvBYtF3pYLE6+fcXm wOSxZMlPJo+u9tssAUxRXDYpqTmZZalF+nYJXBnrp/kWzBWqOHjoFksD43q+LkYODgkBE4k/ cyW7GLk4hATamCROXpjGCuFsZJT49HUlM4Rzh0niysZJjF2MnBzCAg4Sc3+8ZwPpFhGwl9i7 vQYkLCRgJdHS0cUKYrMJqEpMX9PCBGLzAsU3nvjEDmKzAMXPv3nODGKLCsRIvF2/nB2iRlDi 5MwnLCA2p4C1RNuR42A1zAK2Enfm7oay5SW2v53DPIGRfxaSlllIymYhKVvAyLyKUTYlt0o3 NzEzpzg1Wbc4OTEvL7VI11QvN7NELzWldBMjOBhdlHYwTvzndYhRgINRiYc3Y1tHhBBrYllx Ze4hRkkOJiVR3lOngEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeH+8AsrxpiRWVqUW5cOkpDlY lMR5xTUaI4QE0hNLUrNTUwtSi2CyMhwcShK8IW+AGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGi4DU 8BYXJOYWZ6ZD5E8x6nJsuHXlJZMQS15+XqqUOK86MA0ICYAUZZTmwc0BJZGEt4dNXzGKA70l zLsEZBQPMAHBTXoFtIQJaMkF5naQJSWJCCmpBkYHQwdvFpslTJb6abmB0T/PaAhliS795ili JTqreK3evIqlxg1RFvt9At5yck5IXru1MOLcqZdZwbo/JghceHO6t7sh6La41IE1QsVVBTke Jdt2pwqVdESevWWyL/6jRVv6jSmXL0Y8787imlwx8WF3cPfeR+4x09TcugQXhObEt1gdjhNO UGIpzkg01GIuKk4EAEG0J2f9AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZZEbybfug_Tt4yEu5QlPyC7Dp6I>
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: Wed, 25 Jan 2017 18:26:48 -0000

I would recommend making the mobile app the RP, and having the server be 
an additional protected resource that accepts access tokens from the 
mobile app. This is how it's commonly handled, and there are libraries 
(such as Google's AppAuth) that handle most of these interactions.

  -- Justin


On 1/25/2017 9:22 AM, Dario Teixeira wrote:
> Hi,
>
> I am building a mobile app and a server.  The mobile app fetches
> user-specific data from the server, and therefore some sort of
> authentication is required.  I would like to avoid the traditional
> username+password scheme, and instead allow users to login via
> Google or Facebook.  It seems the OAuth2-based OpenID Connect (OIDC)
> is the recommended solution nowadays, so my question is about the
> usage of OAuth2/OIDC in this scenario.
>
> All OIDC docs and tutorials describe the interaction between three
> parties: a Relying Party (RP), a User Agent (UA), and an OIDC
> Provider (OIP).  There are however four parties in my scenario:
> the mobile app, the server, the UA, and the OIP.  Which should
> take the role of RP? I see two different ways to do this:
>
> 1) The mobile app is the RP.  It even takes care of starting a
>    small web server to receive the data from the OIP.  At the end
>    of the interaction, the mobile app has a JWT signed by the OIP,
>    which it sends to the server, which must validate it using a
>    built-in list of OIP public signatures.
>
> 2) The server is the RP.  When the user wishes to login, the mobile
>    app asks the server about the OIP's authorization endpoint.
>    The server provide the client with an URI whose redirect_uri
>    parameter points to the server.  All subsequent steps are
>    handled by the server.
>
> Anyway, this seems like a fairly common scenario, and I would rather
> follow some best-practices documentation instead of cooking up my
> own schemes, like points 1 and 2 above.  Therefore, if there is
> indeed such documentation, could someone please point me towards it?
> And if not, which would be the recommended route, 1 or 2?
>
> Thanks in advance for your attention!
> Best regards,
> Dario Teixeira
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth