-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect value of code_verifier parameter for /v2/oauth/token endpoint #60
Comments
I'm unsure what to make of this report. The example script definitely does base64url encode the code verifier, but by doing that, it doesn't follow https://docs.esi.evetech.net/docs/sso/native_sso_flow.html. This alone would make this an issue for the esi-docs repo. However, I can confirm that the script works both in its current state, and with the spec violating base64url encode removed, meaning the SSO server will accept both a raw code verifier, and one that has been base64url encoded. This is non-standard, undocumented behavior, but one that shouldn't prevent spec compliant libraries from working with the SSO. I would be interested to know why it was introduced in the first place. Finally, you state in your report that the SSO responded with a 500 status code. If there was an issue with the code verifier, the SSO should have responded with a 400 status code, leading me to believe the issue you report was most likely caused by some temporary SSO outage. |
I have a hypothesis. On server side:
base64url_encode() encodes:
So there are no 'good' base64url encoded strings length of 4*n+1! If 'happy way' styled base64url_decode() expects 'well-coded' base64 character string it might be unaware of strings 4*n+1 characters length and results in terrible behaviour (infinite loops, buffer overflow and so on). In such case the server terminates process on timeout with status 500 and execution simply doesn't reach RFC compiant case for the 'bad' string. I checked several code_verifier length: 44 characters. => Success! PS. If a clent uses code_verifier of random length then 25% of token requests will fail with status 500 and CORS error. It might be reason of issue #57 . |
This is the best issue report I've ever received! Thank you. I'll work on a fix :) |
I'd like to point this as an FYI to make sure the code verifiers are correctly generated as well:
This is documented here: https://tools.ietf.org/html/rfc7636#section-7.1 |
Just a tiny note. I'm sure they mean "code_verifier" instead of "code_challenge" in the last sentence, According to RFC7636 4.2 Client Creates the Code Challenge
One can use a 43-octet URL safe string, which is in fact a "code_verifier" with required entropy, as a "code_challenge" only for "plain" method. For "S256" method the string is used "to produce a code_challenge", not "as a code_challenge" For example in section 7.3 they say
|
Bug
Current EVE SSO implementation of /v2/oauth/token endpoint for PKCE uses unnecessary BASE64URL-ENCODING for code_verifier parameter.
According to RFC 7636 Proof Key for Code Exchange by OAuth Public Clients code_verifier and code_challenge parameters are created in following manner:
No additional encoding is required for the parameters sent to the server. RFC 7636, Appendix B provides an example:
In the example, the authorization request includes
code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256
and the request to the token_endpoint includes
code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
There is no additional encoding for the parameters.
This procedure doesn't work for EVE SSO and results in status 500 for POST request to /v2/oauth/token enpoint.
Actual Behaviour
Actual EVE SSO Authorization Code with PKCE behaviour can be reconstructed by python example available here. The example does work with EVE SSO server!
According to the example code_verifier and code_challenge parameters are created in following manner:
First three lines follow RFC 7636 procedure for code_challenge creation.
To follow the RFC, code_verifier value should be equal to value of random string. But in fourth line the example makes additional BASE64URL-ENCODE to calc code_verifier value and this violates RFC 7636.
Expected Behaviour
No additional BASE64URL-ENCODE for code_verifier parameter required on /v2/oauth/token endpoint.
Workaround
One can't use standard OAuth 2.0 RFC 7636 compatible libraries to work with EVE SSO because of the bug. To make them work one can intercept POST request to /v2/oauth/token enpoint and replace code_verifier body parameter with BASE64URL-ENCODE(code_verifier) value.
The text was updated successfully, but these errors were encountered: