[Openid-specs-fapi] [OAUTH-WG] Issuers, Discovery Docs & Brands

[Joseph Heenan]

Hi Francis,

> On 3 Jun 2020, at 18:07, Francis Pouatcha <fpo=40adorsys.de at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200604/346421e0/attachment-0001.html>