Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
<ve7jtb@ve7jtb.com> Wed, 25 January 2017 19:48 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 C8466129B67 for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2017 11:48:37 -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 K7fY0G7k3Rvl for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2017 11:48:30 -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 EAB53129B3E for <oauth@ietf.org>; Wed, 25 Jan 2017 11:48:29 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id 14so66889983pgg.1 for <oauth@ietf.org>; Wed, 25 Jan 2017 11:48:29 -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:from:subject:date:importance:in-reply-to :references; bh=t4YXpnGQzjMgFzg23NKEEFz5RFNf/Jklo+48ZFy0D6A=; b=dz7XLZuFDckgREPAVl9m92k4vuLD4k2nLh+NTZj/GCKgdpuFu4VkljO6Aq+fzV0MOF 9ONssFNpByfawawZ954G5S1mxmA+OH2EHhpejTrsAnCBnKlM08jXCfKWCjCPoCvaAJey vXL6f1InzHkIIMMZbOohDE5xP8rMd85JEJlNJ+DH+XOu84SgswdwnNk04n//kjtkIeil 7jwl7REp5iWLZTPYeLYOcs5b0Vpobti5DQsYrHAYO7+xXV4129mbwYUwP4eixF5D8XBd qK6PfjcaEACn3FuO7pcCI0NyEKmrAMXDu3RMZ5t9pfV95WhSUGkSS3uHXClJVSON4Rst GLPw==
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:from:subject:date :importance:in-reply-to:references; bh=t4YXpnGQzjMgFzg23NKEEFz5RFNf/Jklo+48ZFy0D6A=; b=RLIEVRgr9BlPlV8kEPsw5CIEktO+fgvIlgRY8ZEEHM/BVPeFHpTZI8W0yypsGDGaTJ jEqSGiUF8EURzRAu1S3TJaV2SCu9dREVPp3NvAz94Pe7l+RDNaeRoS7OqMKRMtKSnmNU a7yfJUiS8z2aKS/zuNqEb8RDEGZBbYPYTUlzktJLu0aJCfh77zp1Gius4xjiip4GKs2d 2c3eEhoBi359kNmiNxwKW0bf3N7Lc6koJH9J+m/3Q0S0ZBe+WEDPuDlKQy7l5kP5a8rC hUj9+r0jOMSQevkdiuuRQAMXv7OG6lU2pGWt8iE1scttTyncYttBZAloNICJg6PgQZep Dd6Q==
X-Gm-Message-State: AIkVDXIEhbEkCti3xI6FDLqF1b+Jv1eCt3LfGHDMZ9xVuFjD1ej75Lw+JctZbAw9nPiyND96
X-Received: by 10.84.238.1 with SMTP id u1mr6244486plk.174.1485373709331; Wed, 25 Jan 2017 11:48:29 -0800 (PST)
Received: from ?IPv6:::ffff:10.181.87.102? ([64.114.255.114]) by smtp.gmail.com with ESMTPSA id p6sm3056092pfg.6.2017.01.25.11.48.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 11:48:28 -0800 (PST)
Message-ID: <5889010c.06d0620a.31d79.5dd8@mx.google.com>
MIME-Version: 1.0
To: Dario Teixeira <dario.teixeira@nleyten.com>, "oauth@ietf.org" <oauth@ietf.org>
From: ve7jtb@ve7jtb.com
Date: Wed, 25 Jan 2017 11:48:28 -0800
Importance: normal
X-Priority: 3
In-Reply-To: <ffc794a133b4b5fb341a0590c6848034@nleyten.com>
References: <ffc794a133b4b5fb341a0590c6848034@nleyten.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="94eb2c1ce78451f4fe0546f08403"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/XgWIbVHrnoFsalr0Oyqt9BxdxR0>
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 19:48:38 -0000
There are a number of patterns that people use. I prefer the AppAuth pattern where the native app is a OAuth client to your server and you are protecting your API with OAuth. Your AS becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and uses federated or local authentication to issue tokens. (this gives your backend API access to user info) The other pattern is for the native app to be a Connect client to Google or other IdP and then passes a id_token (not access token) to your backend in some secure manor and your backend validates the signature on the id_token and that it was issued to your client (verification is essential) (the native app gets access to user info api) You still have the problem of how you secure your API, as you need to exchange the validated id_token with something. I thnk that doing this securely winds up being more complicated than the first option. There are other options that may not be allowed by the IdP where your backend is the Connect client and has a client secret. The mobile app makes the request and gets the code back. It then sends code and pkce verifier to it’s backend and the server exchanges it with it’s secret to get a id_token and access token. You still need to add security for your API. (custom scheme redirects for confidential clients may not be allowed depending on the Connect IdP) I think the first option is the best design that gives the best long term design as new IdP can be added without changing the deployed app. John B. Sent from Mail for Windows 10 From: Dario Teixeira Sent: January 25, 2017 7:59 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app 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
- [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