Bungie-net / api

Resources for the Bungie.net API
Other
1.22k stars 92 forks source link

(OAuth flow) %2B (encoded +) in state coming back as %20 (encoded space) #1695

Open TheEvilAmongUs opened 2 years ago

TheEvilAmongUs commented 2 years ago

I'm having an issue validating the state coming back from a request to the OAuth Authorization URL if it contains a '+'. (I'm just base64 encoding a randomly generated byte array and using that as a state.)

Example: URL off to Bungie: https://www.bungie.net/en/oauth/authorize?client_id=[redacted]&response_type=code&state=Y0KE539Is%2BcX3Gw5KkcI%2Fbt%2FBWAxO2eKWQeqvi%2FF8mI%3D

State: Y0KE539Is+cX3Gw5KkcI/bt/BWAxO2eKWQeqvi/F8mI= Encoded State: Y0KE539Is%2BcX3Gw5KkcI%2Fbt%2FBWAxO2eKWQeqvi%2FF8mI%3D

Redirect URL back to my site: https://localhost:7229/signin?code=[redacted]&state=Y0KE539Is%20cX3Gw5KkcI%2Fbt%2FBWAxO2eKWQeqvi%2FF8mI%3D

State: Y0KE539Is cX3Gw5KkcI/bt/BWAxO2eKWQeqvi/F8mI= Encoded State: Y0KE539Is%20cX3Gw5KkcI%2Fbt%2FBWAxO2eKWQeqvi%2FF8mI%3D

Oddly, this appears to only happen the first time a user goes to the authorize endpoint. I'm assuming that this is due to the first authorize request redirecting to https://www.bungie.net/en/User/JoinUp where the user would sign in to their Bungie account. (The encoded '+' must get lost in translation somewhere.)

pancakeslp commented 2 years ago

Disclaimer just a guy, not a bungie dev

I think you are URL encoding (also know as percent encoding) state not base 64 encoding state

If I base64 encode your state using the btoa method in the browser it would look like WTBLRTUzOUlzK2NYM0d3NUtrY0kvYnQvQldBeE8yZUtXUWVxdmkvRjhtST0= https://developer.mozilla.org/en-US/docs/Web/API/btoa

Also I would not expect base64 used in URLs to contain plus or space. There is a special version of base64 called base64url where the plus and slash characters are replaced for other symbols. https://en.wikipedia.org/wiki/Base64#URL_applications

In my experience most developers will consider plus and space are interchangeable when used in a post or in form data sent via URL.

TheEvilAmongUs commented 2 years ago

The state I had provided was already base64 encoded.

If I were to base64 encode it again it would end up being WTBLRTUzOUlzK2NYM0d3NUtrY0kvYnQvQldBeE8yZUtXUWVxdmkvRjhtST0=.

Good shout at base64url. I wasn't aware of RFC4648. That provides me a "better" (compliant with some standard) solution than simply removing the +'s (as I have been doing).

I would generally agree that plus and space can be interchangeable in a URL. However, in the case where the returned value is expected to exactly match what was sent initially, I suspect this would be an exception to that.