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

[Francis Pouatcha <[e-mail]>]

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" and a green styled "
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>".

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" for
reauthentication. If the user opens his personal banking application on
another tab, "Client-Consumer" will send the user to "
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?


>
> 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",
>       "description": "loadsmoney business banking customers",
>       "logo_url": "https://loadsamoney/business/logo.png"
>     },
>     "personal": {
>       "authorization_endpoint": "https://loadsamoney/consumer/auth",
>       "description": "loadsmoney personal customers",
>       "logo_url": "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 am in favor of pushing those changes into target AS-Deployment specific
customizing.
/Francis

>
> Dave
>
>
> On Wed, 27 May 2020 at 16:09, Francis Pouatcha <fpo=
> [e-mail]> wrote:
>
>>
>>>
>>> Message: 1
>>> Date: Tue, 26 May 2020 09:03:16 +0300
>>> From: Vladimir Dzhuvinov <[e-mail]>
>>> To: [e-mail]
>>> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
>>> Message-ID: <[e-mail]>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> My understanding of the branding concept was to present different UIs to
>>> resource owners during login and authorization, while keeping the OP /
>>> AS the same, meaning identical issuer. In a spec it would be helpful to
>>> spell out what branding means (and what not).
>>>
>> Let us call this varian the AS-Brand.
>> As an RO, I sign in for AS-Brand-A and my token is usable under the
>> context of AS-Brand-B because both share the same issuer.  This kills
>> transparency at the RO site.
>>
>> I support: One AS-Brand <-> One Issuer.
>>
>> Regards
>> /Francis
>>
>>>
>>> Regarding a token being issued for "personal" vs "business" and
>>> confusion - the usage of the token is normally defined by its scope and
>>> audience (RS) and if this rule is observed (and it's not relied solely
>>> on the issuer URI for that) then clients shouldn't get confused here.
>>>
>>> Vladimir
>>>
>>> On 23/05/2020 06:26, Francis Pouatcha wrote:
>>> > - I will go for Option 1 even if we have the same runtime instance
>>> > producing tokens under different?issuer uris.
>>> > - Option 2 might expose security risk as many clients rely on
>>> > the?issuer to associate the? token with authorization context. By no
>>> > way shall a token issued for "personal" be valid for "business".
>>> > Therefore considering?the?use of the?same issuer here might lead to
>>> > confusion at the?RP.
>>> > - In order to avoid confusion, AS must make?sure each "brand"
>>> > uses?separated key material to produce the token.
>>> >
>>> > BTW:
>>> > The term brand as used in the context of most Open Banking initiatives
>>> > refers to entities consuming the Interface provided by TPPs (Third
>>> > Party Providers).. TPPs play the roles of RPs in the oAuth2 context.
>>> >
>>> > Unless I misunderstood this thread we are using a brand here to refer
>>> > to an AS virtual host (issuer-uri).
>>> >
>>> > Going forward, we need?to?agree on choosing another term to refer to
>>> > issuers, and leave the term "Brand" for consumers of TPP-interfaces.
>>> >
>>> > The core brand problem we will be facing in open banking is for having
>>> > the AS display the "consumer-brand" logo to the RO in the consent
>>> screen.
>>> >
>>> >
>>> >     >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov
>>> >     <[e-mail] <mailto:[e-mail]>> wrote:
>>> >     >>
>>> >     >> With that said it makes sense to devise a structure which can
>>> >     accommodate UI driven as well as automatic choice.
>>> >     >>
>>> >     >>? ? ? ? The UI driven chooser will need a human readable
>>> >     description and other UI hints. This can work for instance with
>>> >     "classic" OIDC Discovery.
>>> >     >>
>>> >     >>? ? ? ? The "auto" chooser will need some sort of an ID. For a
>>> >     bank chooser this means providing the issuer URI and an optional
>>> >     brand ID and both must get registered together. Or, one could
>>> >     define a standard brand ID (label) for banking operations and if
>>> >     the "alternative_authorization_endpoints" is present look for it
>>> >     in the structure, else fall back to the default
>>> >     "authorization_endpoint".
>>> >     >> Here is one possible layout which has IDs and UI hints:
>>> >     >>
>>> >     >> {
>>> >     >>? ?...
>>> >     >>? ?"alternative_authorization_endpoints": {
>>> >     >>? ? ?"banking": {
>>> >     >>? ? ? ?"authorization_endpoint":
>>> >     >> "https://loadsamoney/business/auth"
>>> >     >> ,
>>> >     >>? ? ? ?"description": "loadsmoney business banking customers",
>>> >     >>? ? ? ?"logo_url":
>>> >     >> "https://loadsamoney/business/logo.png"
>>> >     >>
>>> >     >>? ? ?},
>>> >     >>? ? ?"personal": {
>>> >     >>? ? ? ?"authorization_endpoint":
>>> >     >> "https://loadsamoney/consumer/auth"
>>> >     >> ,
>>> >     >>? ? ? ?"description": "loadsmoney personal customers",
>>> >     >>? ? ? ?"logo_url":
>>> >     >> "https://loadsamoney/consumer/logo.png"
>>> >     >>
>>> >     >>? ? ?}
>>> >     >>? ?}
>>> >     >> }
>>> >     >>
>>> >     >>
>>> >     >>
>>> >     >> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>>> >     >>> I think an id or label per endpoint set would be needed to
>>> >     determine the set of endpoints to be used by a certain client.
>>> >     >>>
>>> >     >>> On the conceptual side, I?m asking myself how the complete
>>> >     process is supposed to work. Who is deciding what issuer/endpoint
>>> >     set combination to use. I assume in an open banking scenario,
>>> >     there will always be some kind of bank chooser. Will this chooser
>>> >     provide the client with issuer and brand id?
>>> >     >>>
>>> >     >>>
>>> >     >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov
>>> >     <[e-mail] <mailto:[e-mail]>>
>>> >     >>>>? wrote:
>>> >     >>>>
>>> >     >>>> A mapping like the one you propose can definitely work. Since
>>> >     the user will be making the choice which endpoint to take with the
>>> >     client app, having the logo_uri is a good idea. If the branded
>>> >     endpoints differ somehow in policy one could also allow inclusion
>>> >     of the op_policy_uri and op_tos_uri params from Discovery.
>>> >     >>>>
>>> >     >>>>
>>> >     >>>>
>>> >
>>> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
>>> >     >>>>
>>> >     >>>>
>>> >     >>>> Vladimir
>>> >     >>>>
>>> >     >>>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>> >     >>>>
>>> >     >>>>> Thanks for your thoughts Vladimir!
>>> >     >>>>>
>>> >     >>>>> The client_id based solution I wasn?t previously aware of -
>>> >     unfortunately it doesn?t solve the problem for app2app, as the
>>> >     mobile OS selects the app to use based purely on the URL (and in
>>> >     at least the iOS case will not offer the user a choice if multiple
>>> >     apps claim to handle the same url).
>>> >     >>>>>
>>> >     >>>>> I think some kind of mapping like you suggest will work and
>>> >     fallback, I wonder about a structure in the authorization server
>>> >     metadata something like this:
>>> >     >>>>>
>>> >     >>>>> {
>>> >     >>>>>? ?...
>>> >     >>>>>? ?"alternative_authorization_endpoints": [
>>> >     >>>>>? ? ?{
>>> >     >>>>>? ? ? ?"authorization_endpoint":
>>> >     >>>>> "https://loadsamoney/business/auth"
>>> >     >>>>> ,
>>> >     >>>>>? ? ? ?"description": "loadsmoney business banking customers",
>>> >     >>>>>? ? ? ?"logo_url":
>>> >     >>>>> "https://loadsamoney/business/logo.png"
>>> >     >>>>>
>>> >     >>>>>? ? ?},
>>> >     >>>>>? ? ?{
>>> >     >>>>>? ? ? ?"authorization_endpoint":
>>> >     >>>>> "https://loadsamoney/consumer/auth"
>>> >     >>>>> ,
>>> >     >>>>>? ? ? ?"description": "loadsmoney personal customers",
>>> >     >>>>>? ? ? ?"logo_url":
>>> >     >>>>> "https://loadsamoney/consumer/logo.png"
>>> >     >>>>>
>>> >     >>>>>? ? ?}
>>> >     >>>>>? ?]
>>> >     >>>>> }
>>> >     >>>>>
>>> >     >>>>> And as you say, the existing authorization_endpoint can be a
>>> >     fallback for clients that are unaware of the new spec or prefer
>>> >     the simpler option of just using a single authorization endpoint.
>>> >     Supporting the new spec would allow a better UX though so there?s
>>> >     advantages to client to do so.
>>> >     >>>>>
>>> >     >>>>>> Speaking of mTLS, I'm not sure how the
>>> >     "mtls_endpoint_aliases" can be sensibly combined with the proposed
>>> >     multi-brand spec.
>>> >     >>>>>>
>>> >     >>>>>>
>>> >     >>>>> I think that particular part is not really an issue as mtls
>>> >     isn?t used at the authorization endpoint.
>>> >     >>>>>
>>> >     >>>>> Thanks
>>> >     >>>>>
>>> >     >>>>> Joseph
>>> >     >>>>>
>>> >     >>>>>
>>> >     >>>>>
>>> >     >>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov
>>> >     <[e-mail] <mailto:[e-mail]>>
>>> >     >>>>>>? wrote:
>>> >     >>>>>>
>>> >     >>>>>> Hi Dave,
>>> >     >>>>>>
>>> >     >>>>>> In the absence of such a "multi-brand" spec we have tackled
>>> >     this issue in the past by letting the "brand" be encoded in the
>>> >     client_id. An alternative scenario is to do a "brand" lookup by
>>> >     client_id. Then let the AS render the "branded" authZ endpoint.
>>> >     >>>>>>
>>> >     >>>>>> You're probably aware the mTLS spec is allowing for
>>> >     endpoint aliases, so this is not the first time such as need has
>>> >     occurred:
>>> >     >>>>>>
>>> >     >>>>>>
>>> >     >>>>>> https://tools.ietf.org/html/rfc8705#section-5
>>> >     >>>>>>
>>> >     >>>>>>
>>> >     >>>>>> One could devise a similar JSON object with mappings
>>> >     "label" - "authorization_endpoint".
>>> >     >>>>>>
>>> >     >>>>>> Clients that are aware of the new spec will look it up,
>>> >     those that are not will fall back to the std
>>> "authorization_endpoint".
>>> >     >>>>>>
>>> >     >>>>>> Speaking of mTLS, I'm not sure how the
>>> >     "mtls_endpoint_aliases" can be sensibly combined with the proposed
>>> >     multi-brand spec.
>>> >     >>>>>>
>>> >     >>>>>>
>>> >     >>>>>>
>>> >     >>>>>> Vladimir
>>> >     >>>>>>
>>> >     >>>>>>
>>> >     >>>>>>
>>> >     >>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
>>> >     >>>>>>
>>> >     >>>>>>> Dear OAuth WG
>>> >     >>>>>>>
>>> >     >>>>>>> We have an issue in the OpenID FAPI Working Group that we
>>> >     believe affects the wider OAuth community.
>>> >     >>>>>>>
>>> >     >>>>>>> In summary: what is the recommended approach to discovery
>>> >     (RFC8414) for Authorization Servers who support multiple "brands" .
>>> >     >>>>>>>
>>> >     >>>>>>> If brands are completely separate, then it seems sensible
>>> >     that each brand must have its own `issuer` and therefore its own
>>> >     discovery document at the correct location (i.e. brand 1 would
>>> >     have an issuer of
>>> >     >>>>>>> "https://as/brand1" and a discovery document available at?
>>> >     https://as/.well-known/oauth-authorization-server/brand1
>>> >     >>>>>>> ).
>>> >     >>>>>>>
>>> >     >>>>>>> However in the real world it is not always so simple. We
>>> >     have many existing implementations in UK open banking that support
>>> >     multiple authorization endpoints. Here is an example (thanks to
>>> >     @Joseph Heenan )
>>> >     >>>>>>>
>>> >     >>>>>>>
>>> >     >>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking,
>>> >     one ?login page? for both business and personal customers.
>>> >     >>>>>>>>
>>> >     >>>>>>>> They have separate mobile apps for business/personal, and
>>> >     are required to support app2app. This means they will definitely
>>> >     be exposing multiple authorization endpoints (as there?s a 1:1
>>> >     mapping of authorization endpoints to mobile apps) - the choice is
>>> >     how they do this.
>>> >     >>>>>>>>
>>> >     >>>>>>>> Their choices are:
>>> >     >>>>>>>>
>>> >     >>>>>>>> 1. Multiple discovery endpoints (one for business, one
>>> >     for personal), each with a different authorization endpoint,
>>> >     multiple issuers (if their vendor allows this)
>>> >     >>>>>>>> 2. Single discovery endpoint, single issuer, multiple
>>> >     authorization endpoints listed in one discovery doc (one for
>>> >     business, one for personal) some of which are hardcoded by the 3rd
>>> >     party
>>> >     >>>>>>>> 3. Multiple discovery endpoints each with a different
>>> >     authorization endpoint, same issuer in all cases (breaks RFC8414
>>> >     and OIDC Discovery)
>>> >     >>>>>>>>
>>> >     >>>>>>> Option 3 is invalid and that leaves us with options 1 and
>>> 2.
>>> >     >>>>>>> Option 1 can be problematic as often it is in reality the
>>> >     same `issuer` behind the scenes.
>>> >     >>>>>>>
>>> >     >>>>>>> We would like to get feedback on this issue and
>>> >     potentially an extension to RFC8414 to allow the definition of
>>> >     multiple authorization endpoints.
>>> >     >>>>>>>
>>> >     >>>>>>> Thanks in advance
>>> >     >>>>>>>
>>> >     >>>>>>> Dave Tonge
>>> >     >>>>>>> Co-Chair FAPI WG
>>> >     >>>>>>> Open ID Foundation
>>> >     >>>>>>>
>>> >     >>>>>>>
>>> >     >>>>>>>
>>> >     >>>> --
>>> >     >>>> Vladimir Dzhuvinov
>>> >
>>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/