Describe the bug PermitAll routes returns 401 when token is provided, but expired. Main problem with BearerTokenAuthenticationFilter which throws exception when token isn't valid, so request doesn't reach WebExpressionVote to get that this route have PermitAll attribute. I think we can do not throw exception and just pass to the next filter(like we do when token isn't provided), but I'm not sure what to do with error.

To Reproduce 1. Add spring-boot-starter-oauth2-resource-server to get BearerTokenAuthenticationFilter 2. Send request with invalid token to 'PermitAll' route

Expected behavior Even when we provide not valid token, PermitAll routes must be accessible.

Sample

A link to a GitHub repository with a minimal, reproducible sample. In README described how to run it(it contains script to run Keycloak, or you can use another SSO)

If it's a bug I would like try to fix it

Comment From: marcusdacoregio

Hi @stillya,

If the token is expired, you can detect that from the client side and not send it. If it is not expired but another claim is invalid, I think it is better to throw an exception than let the request go through.

However, in BasicAuthenticationFilter there is a ignoreFailure property to continue the filter chain, but I don't think it is something that could fit into BearerTokenAuthenticationFilter. I'll ask @jgrandja for his input on this.

Comment From: stillya

Sure I can, but it's not obvious that I could got 401 on unsecured routes. Maybe mention this behaviour in documentation if it's not gonna be fixed?

Comment From: jgrandja

@stillya Sending a bearer token to /info/permit is an invalid request and is a bug with the caller. A bearer token is a credential and credentials should only be passed to protected endpoints. If a request is sent to a public (unprotected) endpoint then there is no need to send any credentials.

I'm going to close this as the bug is with the caller and should be fixed there to ensure the request is valid.

Comment From: SahilSeewal1

This not seems issue at caller end instead seems issue at springboot. Because it is recommended to use httpOnly cookie to store and share the token at client side.

Note: Browser or javascript cannot read and temper this token, that is why it is recommended way to work with token at client side, moreover prevents token abuse.

Link: https://dev.to/costamatheus97/battle-of-the-cookies-regular-cookies-vs-http-only-1n0a#:~:text=However%2C%20since%20HTTP%2Donly%20cookies,server%20with%20each%20HTTP%20request.

Kindly correct this issue at springboot level only, as it is expected behavior that public API should work fine regardless of the access token state sent either in Authorization header or httpOnly cookie.