Reusing endpoints for an API with another authentication method


#1

Hi,

Currently having a good time with silhouette now that I understand the basics. I based my work off the great React template that was provided.

I’m currently trying to double my endpoints so that they can be used with either API key authentication or cookie auth as in the template. I understand that each endpoint can only have one auth provider, so is there a decent way to work around this limitation? Maybe have two endpoints (one for cookies, one for API keys) that call the same method would be a good strategy? Is there an example for this?

Thank you


#2

Hi,

if you follow the pattern of thin controllers and fat models, then you normally have your complete logic inside service classes. You can then use this in different endpoints or other service classes. But to answer your question, to workaround this limitation you should double your endpoints and call the same method.

Best regards,
Christian


#3

Thank you. That makes sense. I have one more question somewhat related but not really. I noticed in your examples for the API side you use an extra code field that has some extra detail like auth.signIn.success in addition to the standard HTTP status codes. I’m just curious, where did you discover this pattern/convention?

Thanks


#4

Hi again,

I’m trying to implement this now and I’m just looking for guidance on how to carry on with API key authentication. The idea for my app is that once the user is logged in via username and password, they can create API keys to access my REST API.

What I’ve done so far:

  1. Created another DelegableAuthInfoDAO that stores APIKey which extends AuthInfo. I’m able to save APIKeys to the persistence layer with authInfoRepository.
  2. Created another environment called APIKeyEnv with a DummyAuthenticator and linked that to the User. Added all the bindings in the DI framework (Guice)

My ideas for the next steps:

  1. Extend RequestProvider like BasicAuthProvider and check the headers for the APIKey. Wire that up using DI.
  2. Make a new controller and use the injected APIKeyEnv and proceed as normal using silhouette.SecuredAction.

Is this correct? Or is it simpler? One worry I have is that in my extended RequestProvider, I’m not able to just search if the API key exists since AuthInfoRepository only has methods to retrieve AuthInfo linked to a LoginInfo.

Another idea I have is simply add a RequestProvider to my DefaultEnv which uses CookieAuthenticator. Will this be run?

Thanks!


#5

One worry I have is that in my extended RequestProvider, I’m not able to just search if the API key exists since AuthInfoRepository only has methods to retrieve AuthInfo linked to a LoginInfo.

What do you use as LoginInfo when storing the APIKey? I think it makes more sense to omit an AuthInfo here and store the API key as identifier in the LoginInfo.

Another idea I have is simply add a RequestProvider to my DefaultEnv which uses CookieAuthenticator. Will this be run?

Yes, this is an interesting idea. But I think it would not work, because the default request cycle calls the update method on the CookieAuthenticator which is needed to update the authenticators last used date.


#6

Yes, I ended up doing the approach of using the API key as the identifier in the LoginInfo as you suggest and using the DummyAuthenticator. Works like a charm.

I submitted some edits to the docs to give an example of how to use RequestProviders. Please review when you get the chance.

Thanks again


#7

Thanks for the change request. Merged :+1: