Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

Joseph Heenan <joseph@authlete.com> Thu, 04 June 2020 13:52 UTC

Return-Path: <joseph@authlete.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 BC0123A0ABA for <oauth@ietfa.amsl.com>; Thu, 4 Jun 2020 06:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-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 6_1GO_9rOqlv for <oauth@ietfa.amsl.com>; Thu, 4 Jun 2020 06:52:21 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 D3C513A0ABC for <oauth@ietf.org>; Thu, 4 Jun 2020 06:52:20 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id g10so5318830wmh.4 for <oauth@ietf.org>; Thu, 04 Jun 2020 06:52:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=if/Lit+CdvU/OafEqNhjQD6uj29uzOE7110G5p3xPvQ=; b=atnIxmHLqdx6a6fRRm2oIsc45420BKf0aHFSCAKSOQg2jzfp/fPMOd6rcze0rbGvjo V+7OqSjAacT4PpAMdGX2tzKVJkaYLwHbFpZdAIEx2ek4eGJVFh96le4HpUF8UlJvIuus qhBbF0xgdRrU0+5Plx1zMpLhpdIt4JSYV8vx61+KorjXmZ2M1+nLNkjPhmvaT3k4+hEI av6uVjaDOkkz/hcrsYKDYooYScTZA3brK0/kfasPa6q1ggpK9sKDea8MlHwfn8X4H7wA IdEZHsJgDK1y3CJ0r8yYK8QSbVEZrurWUQpg2t2CM7dcCUxHnMERRqGAGBU6bZwYa1Sy 3B/A==
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=if/Lit+CdvU/OafEqNhjQD6uj29uzOE7110G5p3xPvQ=; b=razpYqTzc2rLlQLAtopZosGVDsCyVpUzteh2bt9ZNAkktbfEWe2C8MSw5fzxkjYCuk FpSlwhPjuFUxZx8pi3083R5w/AK/i5gwDXJYMQi+0TOGiDtUWgLiZekj5i3cQ6Ax0oRH 87/v1Bs8zjFBUOeqPT9AvW2hrCzBV1aeBsEOetXwvRYJfu92WnY+TwISUPuSKHCXzuWL tcitBGMQXpycCkUgELaxqAKO0W+aOzRocU9folULPRZLXzvFsN6GIqPy4Mkp+y7A6wK8 QCbelE8rflAYDiWdjQYpcH3x1IrtD9UI/9JQfQc4C/KWOhNdysVz1M2hoyLBvfBKmr3X fdhQ==
X-Gm-Message-State: AOAM530pyzQROdKarbwqMVtN0dyf1hnLgOYOhW8VDXngUcgJDBKPBukl tXXrcnesj0BvRN/ZKrj3zL1EdQZD2xIeqOt3
X-Google-Smtp-Source: ABdhPJxw/lurCouKxTQZ7Qt6mXOM2qmTKYOqGKK7Pt+r519F91mFc8Cz7kVgC2HxzjisWkF7TRIsug==
X-Received: by 2002:a1c:305:: with SMTP id 5mr4123326wmd.60.1591278735906; Thu, 04 Jun 2020 06:52:15 -0700 (PDT)
Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id t188sm2523782wmt.27.2020.06.04.06.52.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 06:52:15 -0700 (PDT)
From: Joseph Heenan <joseph@authlete.com>
Message-Id: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B195026-3D5A-4424-A140-B705CC20F7FF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 4 Jun 2020 14:52:14 +0100
In-Reply-To: <CAOW4vyNfwRLuNDXg2fVDPVRov_REKYR+KirgDPUq-AdwW4s+mw@mail.gmail.com>
Cc: Dave Tonge <dave.tonge@momentumft.co.uk>, Openid-specs-fapi <openid-specs-fapi@lists.openid.net>, OAuth WG <oauth@ietf.org>
To: Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>
References: <mailman.1608.1590473008.8861.oauth@ietf.org> <CAOW4vyONovS7SLPnTpoGVoi5T92M7tMDbQ4N4o3hGodQRssqSQ@mail.gmail.com> <CAP-T6TT3yo8NhLOGhk3XmPDJJaR6nccjigGSM=VuauysekhV2g@mail.gmail.com> <CAOW4vyNfwRLuNDXg2fVDPVRov_REKYR+KirgDPUq-AdwW4s+mw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EcEdWyhOXc7U46GNPveIbB4N9Z8>
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
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: Thu, 04 Jun 2020 13:52:23 -0000

Hi Francis,

> On 3 Jun 2020, at 18:07, Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org> wrote:
> 
> Hello Dave,
> 
> I agree that the best deployment option is: 1 brand = 1 issuer = 1 discovery doc, however that is not always possible.
> 
> I'd like to understand Francis what particular issue you see from allowing an AS to specify multiple authorization_endpoints?
> Confusing End User! A user is using the same credentials on a yellow styled "https://loadsamoney/business/auth <https://loadsamoney/business/auth>" and a green styled "https://loadsamoney/consumer/auth <https://loadsamoney/consumer/auth>". A well designed environment will have a centralized page for login and account management like "https://loadsamoney/accounts/auth <https://loadsamoney/consumer/auth>" even better "https://accounts.loadsamoney/auth <https://loadsamoney/consumer/auth>".

In the cases Dave and I are thinking of, there’s no SSO between the different brands (sorry,I’m struggling to find a better word than brands!), which also have segmented user credentials - there’s no user confusion.

> 
> I can see that to avoid user confusion it would be necessary for the Client to record which endpoint they redirected the user to, in case they need the user to re-authorize - but I can't see any particular security issue?
> Let assume the "Client-Business" will record the business auth-endpoint and keep sending RO to "https://loadsamoney/business/auth <https://loadsamoney/business/auth>" for reauthentication. If the user opens his personal banking application on another tab, "Client-Consumer" will send the user to "https://loadsamoney/consumer/auth <https://loadsamoney/consumer/auth>". For SSO to work, the AS has to store the SSO-Cookies under "https://loadsamoney/ <https://loadsamoney/consumer/auth>". Now your AS SSO Cookies are also accessible to "https://loadsamoney/blog <https://loadsamoney/consumer/auth>"! This problem is even worse if instead of path you use subdomains like "https://business.loadsamoney/auth <https://loadsamoney/business/auth>" and "https://consumer.loadsamoney/auth <https://loadsamoney/consumer/auth>" the the SSO Cookie of your AS has to be set to: ".loadsamoney", providing access to the SSO Cookies to all other subdomain hosted application like "https://blog.loadsamoney/ <https://loadsamoney/consumer/auth>".
> Most AS I have used in customer projects use cookies to manage SSO?

I think this is either mainly an issue with the example urls, or solved by pointing out that you should not do SSO between different authorization endpoints for the reasons you say?

>  
> 
> No matter which authorization_endpoint the user was sent to, after the user is redirected back to the Client's redirect_uri the process is the same as if there had been 1 authorization_endpoint. 
> AS UI customization is being done today by many AS deployment because of:
> - Multitenancy of deployment
> - The need to have client identity disclosed to the RO in a consent page

> 
> I am in favour of Vladimir's suggestion of:
> 
> "alternative_authorization_endpoints": {
>     "banking": {
>       "authorization_endpoint": "https://loadsamoney/business/auth <https://loadsamoney/business/auth>",
>       "description": "loadsmoney business banking customers",
>       "logo_url": "https://loadsamoney/business/logo.png <https://loadsamoney/business/logo.png>"
>     },
>     "personal": {
>       "authorization_endpoint": "https://loadsamoney/consumer/auth <https://loadsamoney/consumer/auth>",
>       "description": "loadsmoney personal customers",
>       "logo_url": "https://loadsamoney/consumer/logo.png <https://loadsamoney/consumer/logo.png>"
>     }
>   }
> This use case is neither multi tenancy nor the disclosure of the client identity in a consent page. Starting with the logo here, we will end up adding css and js code snippets. This type of customizing shall be done in the AS-Deployment without playing around with the public AS metadata. 

I don’t understand why “disclosure of the client identity in a consent page” is relevant here; that already happens, it will continue to happen in the same way and isn’t affected in any way by this suggestion.

Yes, there are other architectures that don’t require this. I don’t think it is the job of the protocol to disallow or make some architectures difficult just because other architectures are better.

I don’t think it’s even clear that having a client deal with 16 different issuers for a single bank (a real world example of what would happen if we forced ‘one authorization endpoint per issuer’) is actually “better”. It’s a pain for the client to manage 16 different issuers rather than 1 with 16 authorization endpoints - it means 16 client registrations and 16 issuers to configure, and it obfuscates to the client that these are actually all the same system. I have a hard time saying that one architecture is clearly good and that the other should clearly be disallowed unless you’re willing to go outside of the standards, particularly when switching architectures is a large breaking change that would be close to impossible to coordinate in any real world system with a number of active OAuth clients.

> I am in favor of pushing those changes into target AS-Deployment specific customizing.

Many authorization servers are already running multiple authorization endpoints. They are required in certain architectures, and there are no other security concerns raised so far that are unique to those architectures. (The need to do SSO sensibly and securely applies to all architectures.)

The suggested new metadata allows authorization servers to publish these multiple authorization endpoints in a standard machine readable format that clients can then use with less need for manual configuration and poking around emails or ‘dev portals’ to find the details. I do not see a downside of allowing this.

Thanks

Joseph