Multi-tenant solution

[nsarno]

Multi-tenant solution

[gustavovnicius]

@jaredcwhite, in your app each tenant has its own subdomain?

[jaredcwhite]

each account would have its own subdomain / domain, yes

[jaredcwhite]

but it would all be served from a single API

[gustavovnicius]

Why the need to have a custom audience and signature in this case? I mean, are you intending to share the same JWT between the subdomains? How? The way I see it, similarly to Slack, your app's users should explicitly login on every domain that they wants to be logged in, by doing that, the JWT's wouldn't be shared between accounts / "sessions". I got it right?

[jaredcwhite]

I'm thinking of going with a different solution now so this may be moot. I had been thinking of using multiple Auth0 app accounts (one for each customer) as a prerequisite for using my API, but now I'm looking at rolling my own auth strategy. I still think this is a feature worth considering though.

[nsarno]

I think I want to specify token claims like audience and expiration at the user model level. You might want a different expiration time for users and admins for example. Generally, I'm trying to make sure the payload can be anything you want even though it's not entirely the case yet. So it will be addressed at some point. I'm not sure I understand the need of having a different token signature though.

Thanks for the feedback 👍

[lukeivers]

I'd like to piggyback on this because I'm doing something extremely similar and don't really have the capacity to roll my own auth solution.

Here's what I'm doing:
I make custom apps for clients. Each app has its own associated Client in Auth0. However, there's a single backend/API which all custom apps use to provide their functionality.

Right now when setting up knock via initializer, I'm required to specify the client secret and client key for the Auth0 Client which I'm using to authenticate users.

The users are actually logging in via the mobile SDK for Auth0 and passing their authenticated information to the backend. I simply need to be able to verify (preferably transparently) against multiple Auth0 Clients to determine if the passed in credentials are valid.

Is there any way to accomplish this?

I could easily pass something from the app authenticating the users to the backend telling it which Auth0 Client it should use to validate the token, but I don't know where I would inject code to have it use the custom key/secret for that client.

[lukeivers]

After looking at this more all day today, I think it would be almost trivial to add the ability to do all sorts of custom things including multi-tenancy if Knock would just pass the request object into the Procs used for token_audience and token_secret_signature_key.

Then I could pass in request parameters, http headers, etc, as a way to pass custom information that I could use in those Procs to determine what audience and secret key to choose for a given request.

Basically, knock is part of the request/response cycle, and as such, should be given access to the appropriate request variables just like any other middleware is (not that Knock is implemented as Rack middleware, but it functions as middleware nonetheless).

As a matter of fact, the only reason I can't already do this is because of the layer of indirection caused by the AuthToken model. If not for that, the Proc would be evaluated in context of the controller, and would already have access to the request object. If the AuthToken model had an attr_accessor for :request and took a request parameter in the initialize call, we'd be all good to enable the audience and key procs to access request information and make smart decisions from there.

[lukeivers]

Final follow up:

I now have this working. I am using grape-knock as a wrapper, and I have it pass in the request object as a parameter when creating the AuthToken, which is then stored and handed over to the procs when the appropriate private methods within AuthToken are called.

I can then dig out request parameters, http headers, whatever dynamic info I need as part of the request, and use them to dynamically specify the audience and secret key.

If anyone else is aiming to do this, let me know, I can point you at the updates I had to make to knock, grape-knock (which shouldn't be necessary, but haven't bothered to figure out how to patch knock to work without grape-knock because that's not my use case), and my knock initializer in order to make this work.