jwtauth.eesecurity.JWTProcessingException

Hi to all,

after this issue (Bug Report: java.lang.LinkageError while classloading “com.nimbusds.jwt.JWTClaimsSet” FISH-5941 (Issue #5533) was finally solved in the 5.2022.2 version, I was happy to update from 2021.5. But now, I have to recognize, that the “invalid token” behavior has changed in that case, that now only a “fish.payara.microprofile.jwtauth.eesecurity.JWTProcessingException: fish.payara.microprofile.jwtauth.eesecurity.JWTProcessingException: JWT token expired” is thrown, when an expired token was provided.
This is now a real problem for me, because I don’t have the chance anymore to catch it and provide some additional error information for the client. In version 2021.5, a had the change to validate the Token via a normal WebFilter (with Priorities. AUTHENTICATION), and I could provide the client with our general error structure, and if the token was valid, the “normal MP-JWTauthentication” with the SecurityContext was done afterwards. That was perfect.
But now, in addition, the server log is filled with the complete stacktrace:

fish.payara.microprofile.jwtauth.eesecurity.JWTProcessingException: fish.payara.microprofile.jwtauth.eesecurity.JWTProcessingException: JWT token expired
	at fish.payara.microprofile.jwtauth.jwt.JwtTokenParser.parse(JwtTokenParser.java:152)
	at fish.payara.microprofile.jwtauth.eesecurity.SignedJWTIdentityStore.validate(SignedJWTIdentityStore.java:116)
	at javax.security.enterprise.identitystore.IdentityStore.validate(IdentityStore.java:85)
	at fish.payara.microprofile.jwtauth.eesecurity.SignedJWTIdentityStore$Proxy$_$$_WeldClientProxy.validate(Unknown Source)
	at org.glassfish.soteria.cdi.DefaultIdentityStoreHandler.validate(DefaultIdentityStoreHandler.java:96)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
	at org.jboss.weld.generated.proxiesx.security.enterprise.identitystore.IdentityStoreHandler$1763020431$Proxy$_$$_WeldClientProxy.validate(Unknown Source)
	at fish.payara.microprofile.jwtauth.eesecurity.JWTAuthenticationMechanism.validateRequest(JWTAuthenticationMechanism.java:100)
	at fish.payara.microprofile.jwtauth.eesecurity.JWTAuthenticationMechanism$Proxy$_$$_WeldClientProxy.validateRequest(Unknown Source)
	at org.glassfish.soteria.mechanisms.jaspic.HttpBridgeServerAuthModule.validateRequest(HttpBridgeServerAuthModule.java:151)
	at org.glassfish.soteria.mechanisms.jaspic.DefaultServerAuthContext.validateRequest(DefaultServerAuthContext.java:76)
	at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:391)
	at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:358)
	at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:181)
	at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:487)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:726)
	at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:581)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:520)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:217)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:182)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:156)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:218)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:95)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:260)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:177)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:109)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:88)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:53)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:524)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:33)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:114)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: fish.payara.microprofile.jwtauth.eesecurity.JWTProcessingException: JWT token expired
	at fish.payara.microprofile.jwtauth.jwt.JwtTokenParser.verifyAndParseSignedJWT(JwtTokenParser.java:192)
	at fish.payara.microprofile.jwtauth.jwt.JwtTokenParser.parse(JwtTokenParser.java:147)
	... 45 more
]]

And because an expired stacktrace is somewhat normal and occures very often, the server-log became unreadable.

Is there any opportunity to either avoid the stacktrace (other then change loglevel to WARN ;-)) or fetch the exception and handle it on my own? Or is there some way, an own validation can occur before the MP-JWTauthentication takes place (as it was in 2021.5)?

I am a bit worried because I am stuck in the 2021.5 version and in a few day, the Payara 6 will be released and the 5er is then no longer supported…

Thank you very much for any hint
Ulrich