[OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

Neil Madden <neil.madden@forgerock.com> Mon, 15 March 2021 10:00 UTC

Return-Path: <neil.madden@forgerock.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 7D9DD3A089C for <oauth@ietfa.amsl.com>; Mon, 15 Mar 2021 03:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 66R9ODYnzuCT for <oauth@ietfa.amsl.com>; Mon, 15 Mar 2021 03:00:57 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 97F7D3A0867 for <oauth@ietf.org>; Mon, 15 Mar 2021 03:00:57 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id ci14so64945074ejc.7 for <oauth@ietf.org>; Mon, 15 Mar 2021 03:00:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s6c1syj0TlPj/FcykRTli6hzga77wKeUA2cRs62ufGE=; b=XCbGgxR72eygNh4YEuH5XsadbKgQ7wwmj3N3rKwKgYyOn8bX71/kko23LpEH81/tPP UIo37IXfok1Pkis+LxxQ7qkZjuFI2Qvi9ZLSwspXdxqu4Ny9SlBIa04/L4gaMt4IuXPF 6T8NRdhyJilkIxmiSCsImpwFmk2IKCAdWVXbg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s6c1syj0TlPj/FcykRTli6hzga77wKeUA2cRs62ufGE=; b=FVAR41NWJlvQ2ySXgliVQeLFTrE09HtzX0lHXuNnyrF2PMSurhRFSOqG1NjNzVUFX/ 1wNkI/hzD56vSN+e6OFdvcnyB5E6HX1DB0PmJ+UnOUsaQte2LJyBFiF4TgnvhdgH5sKD K5blH/e9TJlFjFDo2hMpWEjUZpDLzG895oytFa0P5xf89NYPEInkWCa/WlSTfo4zXrjv +VVGlawYG6M5MU+jh/8HlH1otw0AwPTvjiMczpdFsRcSueCztUQtRXg59JMhiLfFeqxp sPA/nWs1KTDsHexWj3r+tl8xS0KXa3vF1iJIJcyJaT+bX2r+O+h11HJ9wkhz5F2g2qr7 51Mw==
X-Gm-Message-State: AOAM530w1pSzvk+ibpaJXTy0/G8a1cFDGmYvXzk35wHN1FQfgMka06fY htonAznk4XE/HYkswfKFnBvUKJg0uUdLy5yp/56FjSrAO7EAD3eQhotClq1JtVgAIllELk15qg= =
X-Google-Smtp-Source: ABdhPJxGMnb/dis0Z/gpcG194rPACIxRPzolcrQh6HMna4bfTyS4XIcMuVa7m5WA3ZDRQ31FnRDhkw==
X-Received: by 2002:a17:907:20f5:: with SMTP id rh21mr22239110ejb.27.1615802454422; Mon, 15 Mar 2021 03:00:54 -0700 (PDT)
Received: from [10.0.0.6] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y24sm7867388eds.23.2021.03.15.03.00.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Mar 2021 03:00:54 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <C63FB3A1-CAEE-491C-8589-127A878559F9@forgerock.com>
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 15 Mar 2021 10:00:53 +0000
In-Reply-To: <8b0b9840-1a80-d06f-316b-8a5273ad2124@aol.com>
Cc: Stoycho Sleptsov <stoycho.sleptsov@gmail.com>, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>, oauth <oauth@ietf.org>, Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
To: George Fletcher <gffletch@aol.com>
References: <CAGL0X-qvLz=gG06Q3mL5yNs5f-eqSwxO-g=K=cDKdmC8VP+UEg@mail.gmail.com> <AE8B3F28-D7B3-4A70-8E0D-2F673970E008@forgerock.com> <8b0b9840-1a80-d06f-316b-8a5273ad2124@aol.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3AFE4961-3920-4421-A44E-5255AA633E37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1z06Sxd5RWOmyogfN2xRbqc-Cq8>
Subject: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 15 Mar 2021 10:01:00 -0000

I want to come back to this topic as a new thread.

As I understand things, the difference on Android is that any app can claim to be a generic web browser and so claim to handle all URIs. Whereas on iOS only specifically vetted apps can claim to be web browsers. Is that correct?

If so, this does seem like a quite large hole in security of OAuth on Android. Should we be considering a new draft recommending alternative measures (such as attestation) on Android? Presumably the same issue is also true on most desktop OS?

— Neil

> On 23 Feb 2021, at 15:20, George Fletcher <gffletch@aol.com> wrote:
> 
> Unfortunately, in the mobile app world this isn't sufficient. On iOS using Universal Links will bind the https redirect_url to your app in a secure way but it doesn't work the same way on Android with App Links. There is still a problem with "mobile app impersonation". If you have an app that you want to ensure is "your" app then the most secure way is to look at "app attestation". This is however, way off topic for this thread :)
> 
> On 2/14/21 9:28 AM, Neil Madden wrote:
>> Public clients are implicitly authenticated by their ownership of the registered redirect_uri. This why it’s important to use a redirect_uri for which ownership can be reasonably established, such as HTTPS endpoints with exact URI matching. 
>> 
>> There are more things that can go wrong with that (see the security BCP), but it can be made reasonably secure. 
>> 
>> — Neil
>> 
>>> On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> <mailto:stoycho.sleptsov@gmail.com> wrote:
>>> 
>>> 
>>> I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS",
>>> with the objective to verify if they are valid.
>>> 
>>> I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example).
>>> If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication.
>>> 
>>> Or is it considered a bad practice to do that?
>>> 
>>> Regards,
>>> Stoycho.
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 


-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>