prevent "Bearer token authentication is required" by passing call to custom error servlet

[george-kay]

we use your jwt-extension in our ear project. When we open deeplinks to secured parts of our war module without token (http status 401) we always get the browser message "Bearer token authentication is required".

We would expect that these calls would be forwarded to our errorservlet (named in web.xml) so we can do the proper forwarding to loginpage and stuff - like for http status 403 - which is working great.

Any chance to do that @ceharris ?

wildfly-jwt-extension/jwt-subsystem/src/main/java/org/soulwing/jwt/extension/undertow/JwtAuthenticationMechanism.java

Line 84 in 522e55c

exchange.putAttachment(JwtAttachments.AUTH_MESSAGE_KEY,

[george-kay]

any ideas how to solve this?

[ceharris]

Sorry for the delay in reply. My Macbook had a hard failure and I've been kinda struggling to get everything back in order while keeping up with work and outside-of-work activities like this.

I'm sure that it's possible to forward to a 401 error page/servlet in the application.

It hasn't been an issue for other users, because the client is typically just using the body of the 401 response (which is a JSON object) to get the URL for the OAuth2 authorization server (token issuer), and then using the standard OIDC configuration endpoint (/.well-known/openid-configuration) to get the URL used to start the authorization code flow to obtain an access token. The OAuth2 framework seems to be a little bit vague on how to handle this "bootstrapping" problem, but this approach has been workable for others who are using this extension. I'd have to imagine that forwarding to a 401 error resource in the application would still need to have the same outcome -- i.e. the client application still needs to do an authorization code flow with the token issuer in order to get an access token.

Forwarding the request to a 401 error page/servlet would require some work using the undertow API in the JwtAuthenticationMechanism, but should be doable with a little digging into the undertow API. Not sure if it's possible to know that such an error page has been defined for a given web app deployment, so it might also require an extra configuration property to let the authentication mechanism know that it should try.