sharpedavid
commented
4 years ago Hi @axandar I'm not a maintainer, but I do use this feature so I decided to have a look. I'm not sure if these extensions are actually vulnerable to the alg=none attack. In both cases Payara communicates directly with the OpenID Provider to get the access token. In neither case does Payara support the Authorization: Bearer ... header. So you can't send an arbitrary request to Payara with a customized JWT: Payara always retrieves it directly from the OpenID Provider, and that connection is over https, so we are guaranteed to get a trusted JWT.
You can see what I'm describing in the diagram on this blog post. Payara exchanges the authorization code for an access token, but it doesn't actually use the access token to authenticate individual requests.
I think if you browse the implementation you should also see this. Payara never accepts a token from a request: it gets the token from the OpenID Provider directly.
The Payara feature that does use tokens directly for authentication and authorization is the Eclipse MicroProfile JWT Authentication API. I haven't looked at the implementation, but the documentation does state "A JWT also must be signed, and in the case of MicroProfile JWT this must be RSASSA-PKCS-v1_5 using the SHA-256 hash algorithm" which sounds promising.
I'm not completely confident, but that's my understanding. If you can point to exactly where this vulnerability exists in the code that would be helpful, but otherwise I don't think this is an issue.
fturizo
Shouldn't there be an option to set expected JWT algorithm? We shouldn't trust which algorithm is provided by JWT - someone could change payload and set algorithm to none.
In Nimbus OAuth 2.0 SDK with OpenID Connect extensions they have check if there was provided algorithm and throws an exception if JWT's algorithm doesn't match.
I see that there is used nimbus-jose-jwt library, why not also use oauth2-oidc-sdk?