2

I'm in the process of building a new API that needs to support multitenancy.

I can figure out how to implement reading and writing the data securely without having to worry about clients being able to know about (or see) other tenants data.

I can also understand how to determine the right tenant for authenticated endpoints (I.E. using a tenant id in a JWT).

For anonymous endpoints however I don't know how to approach this. I came up with the following solutions:

Solution 1:

Add a tenant id as a parameter. I dislike this because I would like the multitenancy to not be part of the resource endpoints.
Pros:

  • Easy to implement

Cons

  • Does not feel like multi tenancy is 'transparent'

Solution 2:

Create a tenant service which can generate an anonymous token (do not set the sub, just a tenant id).
Pros

  • Adds transparency to the multi tenancy
  • In a later stage, this token can be used as an exchange token together with user credentials to authenticate against a multitenant authentication service

Cons

  • Adds another 'authentication endpoint'

Solution 3:

Use application tokens. Each tenant then could have multiple clients which each authenticate with a key and secret. This extends the second solution and has it's own advantages and disadvantages on top: Pros

  • Clients become users themselves
  • Possibility to have scopes

Cons:

  • Adds more complexity (multi tenant clients need to have multiple tokens)
  • Adds more administration, each client needs an application token per tenant

Question

Because this is a crucial part of creating these endpoints (and it can become a lot of them) I would like to hear your opinion about these solutions, and maybe there are other approaches that I can't come up with, maybe there is a pattern for this that I can't find. Your input on this will be greatly appreciated.

Improve this question
2
  • Not sure why you can't just use the JWT. TenantId is just a claim.
    – Yuli Bonner
    Commented Sep 12, 2019 at 14:36
  • It is not about can't, more about what the best solution is (either one of my solutions, like the second one you mention) or one of your own. I'm just curious how other people think about it.
    – LangeJan
    Commented Sep 13, 2019 at 19:32

1 Answer 1

Reset to default
1

Consider passing the tennant as part of the host header. ie

{tennant}.myapi.com/{resource}/{action}

This addresses your concerns about transparency and keeps each tenant separate.

A possible con is that it adds multiple endpoints for multi tenant clients. But this could be considered a good thing in some ways as it maintains separation.

Improve this answer
2
  • I think this is in the same category as my first solution (tenant is part of the resource uri) with some pros and cons. One con you already mentioned but another might be ssl (you need a wildcard certificate per api), except when hiding it behind a gateway which merges multiple api's but then it still adds a lot of complexity. In that case i would prefer myapi.com/{tenant}/{resource}/{action} where some middleware extracts the tenant info.
    – LangeJan
    Commented Jul 11, 2018 at 11:30
  • yes, you are essentially just moving the tenant parameter from the method call to the client constructor in order to get 'transparency'
    – Ewan
    Commented Jul 11, 2018 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.