[Openid-specs-fapi] [OAUTH-WG] Issuers, Discovery Docs & Brands
Francis Pouatcha
fpo at adorsys.de
Wed Jun 3 17:16:10 UTC 2020
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=
> 40adorsys.de at dmarc.ietf.org> wrote:
>
>>
>>>
>>> Message: 1
>>> Date: Tue, 26 May 2020 09:03:16 +0300
>>> From: Vladimir Dzhuvinov <vladimir at connect2id.com>
>>> To: oauth at ietf.org
>>> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
>>> Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6 at connect2id.com>
>>> 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
>>> > <vladimir at connect2id.com <mailto:vladimir at connect2id.com>> 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
>>> > <vladimir at connect2id.com <mailto:vladimir at connect2id.com>>
>>> > >>>>? 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
>>> > <vladimir at connect2id.com <mailto:vladimir at connect2id.com>>
>>> > >>>>>>? 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
>> OAuth at ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
>
>
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200603/b9fd8957/attachment-0001.html>
More information about the Openid-specs-fapi
mailing list