CODEWITHSUNDEEP
javascriptsingle-page-applicationopenid-connect
RHarris
RHarris

Reputation: 11227

OIDC, multi-tenant SPA and wildcard callback

I currently have a multi-tenant SPA application that uses wild-card URL to differentiate tenants and databases. For example https://tenant1.appname.com might tie to database tenant1_db and https://tenant2.appname.com would tie to database tenant2_db.

Currently, the front end SPA is hosted on the same server as the backend .Net API. I use cookie authentication with HTTP Only cookies and because everything is hosted on the same site -- I don't have to deal with CORS or anything like that.

I'm exploring the possibility of authentication from Azure AD using OIDC. My understanding is that RFC specs state that OIDC callbacks MUST be made to an absolute URI. So, I wouldn't be able to callback to things like https://tenant1.appname.com.

I've read a few places that talk about using state to keep track of the tenant and redirect after OIDC login. I'm just curious how this works in regards to the cookies and tracking the tokens. If the callback URL is https://appname.com/callback and then the SPA client forwards to https://tenant1.appname.com, it seems like my cookies/tokens would now be invalid or un-accessible due to the different domain.

Can someone explain how this would work?

Upvotes: 0

Views: 707

Answers (1)

Gary Archer
Gary Archer

Reputation: 29291

Interesting question and I thought I'd post some details based on experience. It may not be a complete answer though.

DESIGN THOUGHTS

I would start with how the simplest option would work, based on systems I have provided for investment banks:

  • All users from all tenants share the same database, APIs and application URLs
  • A tenant ID claim is included in tokens
  • APIs ensure that users from Tenant A can never see data from Tenant B

Customers who are not happy with this can pay extra to get their own dedicated servers and URLs - as you describe. If cookies are used for Tenant A they must not be usable for a Tenant B domain.

A key benefit of this is that you keep your code simple - everything is standard including the callback URL issue you mention. For different tenants you deploy the same code with different configuration settings.

AZURE AD

This has an option to use different OAuth URLs per tenant, and also to include Tenant IDs as claims in tokens. It may not be what you want though, because not all tenants are the same:

  • 90% of tenants may be happy to share the same system - this will be all of the small customers
  • 10% of clients may be willing to.pay extra - this will be the big customers

TECHNICAL SOLUTIONS

Hopefully thets across that there is not usually a magic technical solution to this problem. Sharing cookies across tenants or doing non standard OAuth things can lead to exploits.

ROUTING SOLUTIONS

Another option to consider is around dynamic user routing. You could possibly identify all users in the same system, then route them to the correct URLs dynamically.

Most systems don't support this but in case it gives you some ideas, have a look at this recent article from Curity - in particular the possibilities that reverse proxies provide.

Upvotes: 0

Related Questions