-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only one strategy allowed in Authentication #2139
Comments
@jannyHou , could you please take a look? I think it's related to the authentication work that you're doing. Thanks. |
Hello @sertal70 , I am newbie into LB4 , so apologies if I am talking out of senses ( hehe ). the below solution could be a workaround, i guess ( i have not tried though), Let there be a
Or Call two separate Auth-Component classes from each of 'if' statements ? My thought process was: We donot specifiy the Exact Strategy in AuthProviderClass declaration and only create instance when we are sure of what kind of strategy has been decorated on the controller. So insead of exposing multiple auth provider controllers(each specific to one strategy), we can have our MainAuthController which can route/decide on the response. Please correct me If i misunderstood something. |
Hello @rohit-khanna, thanks for your suggestion and... welcome to the team of LB4 newbie! :) Theoretically it should work as workaround, I'll give it a try (as soon as I have time) to verify that works and, more important, that there are no side-effects. |
@sertal70 , glad to be welcomed in the growing team :) I had two endpoints in my controller , one with 'Basic Strategy' and Other one with 'JwtStrategy'. And with the above code i was able to achieve this. And yes, whenever you have time, you can share your views, this will help us grow.. Cheers :) |
@rohit-khanna I implemented your solution and I can confirm it works, so at least it seems to be a viable workaround until the LB4 team will decide to support more that one auth strategy using the default binding mechanism. Which, IMHO, it should be the preferred way because there is no need to write&mantain a custom auth provider. |
@sertal70 @rohit-khanna The team realized the authentication system should be extensible, story |
@jannyHou very good news, thanks! @rohit-khanna thanks to you for the suggestion! |
This feature is supported after having the extension point :) |
@rohit-khanna It would be great if can u please provide us with some code snippet for this example. |
@Swati-GOT, did you get a chance to look at the sample snippet in https://loopback.io/doc/en/lb4/Authentication-component-decorator.html#authentication-decorator?
|
@dhmlau @jannyHou I have implemented multiple authetication strategy but they are acting as OR either of them passes endpoint is accessible. Is there a way I can make it AND logic so that both needs to pass.
If user provides valid access key but invalid jwt token still gets access to the endpoint. I want to prevent it, user should provide valid access key and jwt token to access resources. |
Description / Steps to reproduce / Feature proposal
Hi, I'm new to loopback, before opening this issue I tried to find a solution in the issues list or in the google discussion but without success, so here I am.
I'm trying to implement a basic use case for authentication. My scenario is:
/login
endpoint passing username and password via a basic http authentication/login
endpoint is decorated with@authenticate('BasicStrategy')
so credentials are checked and, if they are ok, the endpoint creates and returns a JWT to the client/todos/count
endpoint sending the JWT in the Auth header (bearer token)/todos/count
is decorated with@authenticate('JwtStrategy')
so the JWT token is verified and, if it is ok, the endpoint give back the result to the clientCurrent Behavior
Everything goes fine until step 4. where I get the error:
Unhandled error in GET /todos/count: 500 The strategy JwtStrategy is not available.
The root cause is in
application.ts
, where I bind the two strategies for authentication:and, as it is clearly stated in the documentation, only one bind is allowed for the same key.
So it seems that the current design of Authentication would not allow more than one strategy at the same time.
For this simple use case it would not be a problem (it is as simple as removing BasicStrategy, because it is used in
/login
endpoint only and it could be implemented in many different ways).But what about real production scenarios where multiple strategies should be supported?
Expected Behaviour
In a real, complex project, more than one authentication strategy is often a requirement so IMO it should be supported.
The text was updated successfully, but these errors were encountered: