Skip to content
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

Authentication middleware should NOT interfere with Authorization #234

Open
montella1507 opened this issue Oct 17, 2022 · 3 comments
Open

Comments

@montella1507
Copy link

Hi,

Slim-jwt-auth is "Authentication middleware":
This middleware implements JSON Web Token Authentication.

Authentication should:

  • parse and validate token if found
  • add identity of the user to Request (if the token is valid and found)

Authentication SHOULD NOT:

  • prevent any action
  • return 401
  • disallow going to any route

Because it's part of the process which should be handled by AUTHORIZATION middleware.

slim-jwt-auth is authentication middleware , there are several good reasons, why you should not interchange / mix these two terms.

Please do not provide any "authorization" / denial service inside Authentication middleware, it is wrong place to do that and you usually want to sort your middlewares in this way:

...

  • Authentication (parse and validate identity)
  • Routing
  • Authorization

Authentication / Authentication should be split to 2 middlewares and named correctly.

Preventing routes in "authentication" middleware is wrong.

@montella1507
Copy link
Author

The problem is this Behavior - it is wrong.

image

in case the token is not there or invalid, you should do nothing... The part of work of the Authentication middleware is only to parse and validate user identity, not to return 401 when not found.

@tuupola
Copy link
Owner

tuupola commented Oct 22, 2022

Yeah naming things is hard. I do not remember anymore why the class was named JwtAuthentication. In any case changing behavior so that middleware would allow access even when token is missing or invalid is a BC break so such change will not happen.

Allowing access with missing or invalid credentials is also what most users will not expect even though the term "Authentication" is technically wrong.

As a sidenote even HTTP Basic Authentication RFC7617 suggest replying with 401 when credentials are missing. This is not a requirement though.

Upon receipt of a request for a URI within the protection space that
lacks credentials, the server can reply with a challenge using the
401 (Unauthorized) status code 

I will add the word "Authorization" to description to avoid confusion.

@axebox
Copy link

axebox commented Aug 24, 2023

I got here because I was also confused. I was expecting access to the request token regardless of auth success. For example if you have a route that returns default data without a valid token, but return extra data if that token exists (using the identical routing). Would it be possible to configure in this way? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants