JSON parsing failing

[Slugger]

First of all, this filter has saved me hours (and hours) of time already so thank you very much for sharing this!

I'm so close to the end goal I can taste it... the PoC app is secured using this filter, it is denying access as expected. I've generated my access token from the AWS Cognito endpoint, I've sent the bearer token to my app, I can see the filter trying to process it, but it fails:

java.text.ParseException: Invalid unsecured/JWS/JWE header: Invalid JSON: Unexpected token �z��&��B#�#6�F"���w�F����V�%�e4d��tc�F�'#�Wce����D�S�"�&��r#�%%3#Sb' at position 70.
	at com.nimbusds.jwt.JWTParser.parse(JWTParser.java:55) ~[nimbus-jose-jwt-4.23.jar:4.23]
	at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:258) ~[nimbus-jose-jwt-4.23.jar:4.23]
	at com.ixortalk.aws.cognito.boot.filter.AwsCognitoIdTokenProcessor.getAuthentication(AwsCognitoIdTokenProcessor.java:67) ~[ixortalk.aws.cognito.jwt.security.filter-0.0.6.jar:0.0.6]
	at com.ixortalk.aws.cognito.boot.filter.AwsCognitoJwtAuthenticationFilter.doFilter(AwsCognitoJwtAuthenticationFilter.java:54) ~[ixortalk.aws.cognito.jwt.security.filter-0.0.6.jar:0.0.6]

So this looks like the decoding of the access token has failed and so it ends up trying to json parse some binary garbage. I've traced thru the filter up to the point of this failure and it appears that the issue is that the Bearer prefix of the Authorization header is not being stripped before the access token is sent for decoding. I'll submit a PR for my fix, which allows me to parse the JWT as received by my client app.

I believe the Bearer prefix is standard practice? Did some testing using Postman, etc. and it was auto prefixing the Bearer on the Authorization header as well.

[semchev]

I've had the same issues and can confirm that manually removing the Bearer prefix fixes the issue.

[ddewaele]

Thanks a lot for the PR. Merged the PR and released 0.0.7 of the lib to maven central.