This project has moved. For the latest updates, please go here.

Update the ConfigurationOptions for Google Middleware during making a request

Aug 14, 2014 at 5:08 AM

Is it possible for me to update the client id and secret for the Google Middleware Options while making a authorization request [Challenge].

I posted this question in StackOverflow

Kindly let me know if this is possible.
Aug 18, 2014 at 7:11 PM
Edited Aug 18, 2014 at 7:11 PM
No. If you need to work with multiple client IDs then it's recommended to use multiple instances of the middleware.
Aug 19, 2014 at 5:36 AM
Tratcher wrote:
No. If you need to work with multiple client IDs then it's recommended to use multiple instances of the middleware.
Sorry, can you please elaborate on "using multiple instances of middleware" because these are created at the time of application startup. I did not really get to know how this can be accomplished.
Aug 19, 2014 at 5:58 PM
How many client IDs are you attempting to support at once?
Aug 20, 2014 at 4:33 AM
Edited Aug 20, 2014 at 4:42 AM
I have solved this problem with a basic design change in the Authentication Middleware. Instead of each middleware relying on a typed instance of their respective AuthenticationOptions they should rely on a mediating interface instead.

Let's use Facebook as an example. I use a new interface, IFacebookAuthenticationOptions, instead of the concrete implementation FacebookAuthenticationOptions. This allows the developer to inject a different strategy for resolving the AuthenticationOptions, namely the AppId, AppSecret and CallbackPath. In my case I have an implementation called MultitenantFacebookAuthenticationOptions which gets the AppId/AppSecret/CallbackPath on a per-request basis based on the tenant's FB api keys and url.

Of course the UseFacebookAuthentication extensions need to be modified to accept an interface. I also provide a default implementation StaticFacebookAuthenticationOptions that mirrors the existing API so a developer can still use app.UseFacebookAuthentication(appId, appSecret);

I'll put my code up at and I would like to get buy-in from the Katana team to incorporate this design change. I'm happy to implement this work in the Katana code base if we have buy-in.
Aug 20, 2014 at 5:03 AM
Edited Aug 20, 2014 at 5:05 AM
Our Application has a customer management portal, where in we can create / register the customers. Given this case, we will be having any number of customers coming in to the application and using it. Hence, I am not able to give you the exact figures. If we can set the client id and app secret dynamically for each request [serving a customer] can be a good option.

As @kingdango pointed out, if there is a way to accomplish this, it is okay for me. Kindly suggest.
Aug 20, 2014 at 6:31 AM
Katana's OAuth middleware were only designed for single-tenant, there's no supported way to do multi-tenant right now. However, it has been a common request that I think we'll have to explore in the future. In the meantime you're welcome to take our sources and experiment as kingdango has done.

Kingdango, it sounds like you have an interesting approach. Maybe you can team up with seravanand to see how well it works for them. If your version works well for others then you may choose to publish it directly, there's no reason to wait on us. You can also contribute it here:

Note we're in the process of migrating our security components to, so we can continue this discussion over there.
Aug 20, 2014 at 1:07 PM
Awesome, thanks @Tratcher. Before I saw this reply I created this thread for additional discussion on my proposed design change:

I'll checkout the links you provided and get involved! :)