invalid_request for some nonces / user_id when posting to user_nonce_validate

[AronOlio]

I’m following the user verification flow from meta here: https://developer.oculus.com/documentation/native/ps-ownership/#integrate-user-verification

… in order to validate the identity (user id) of a user that I got through invoking the user proof sdk method ovr_User_GetUserProof().

90% of the time, invoking the meta nonce validation endpoint results in a successful validation, when I call this: https://graph.oculus.com/user_nonce_validate using the user id and nonce from ovr_User_GetUserProof().  But for 10% of my users, I get a invalid_request from the service!

I'm invoking this endpoint in a nodejs service like this: 

    const verifyRequestPayload = {
        access_token: `OC|${appId}|${appSecret}`,
        nonce,
        user_id: `${userId}`,
    }

    const response = await axios.post(`${oculusServerHost}/user_nonce_validate`, verifyRequestPayload)

 Calling with a string or number `user_id` makes no difference; some users always end up with invalid_request response from the server.

'content-length': '190'
  connection: 'close',
date: 'Tue, 09 May 2023 07:34:16 GMT',
'x-fb-debug': 'XXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==',
'x-fb-rev': '0000000000',
'x-fb-trace-id': 'XXREDACTEXX',
'x-fb-request-id': 'XXXXXREDACTEDXXXXXXXX',
expires: 'Sat, 01 Jan 2000 00:00:00 GMT',
  'cache-control': 'no-store',
  pragma: 'no-cache',
'strict-transport-security': 'max-age=31536000; preload; includeSubDomains',
  'access-control-allow-origin': '*',
'oculus-api-version': 'v1.0',
'www-authenticate': 'OAuth "Facebook Platform" "invalid_request" "Parameter user_id: invalid user id: 9XXXXXXXXXXXXXXX"',
'content-type': 'application/json; charset=UTF-8',
  vary: 'Origin',​

(above are the response headers from meta; identifying information redacted for safety).

const response = await axios.post(`${oculusServerHost}/user_nonce_validate`, verifyRequestPayload)

 
I’ve noticed a pattern where almost all the rejected ones start with 9xxxxxxxx, and the accepted ones start with 5xxxxxxx or 6xxxxxxx.

Does this make sense to anybody? Is meta systematically rejecting userids within a range, or does the nonce only apply to user ids within a particular range?

[thecodexter]

Wondering if there is a difference between using ovr_User_Get() vs. ovr_User_GetLoggedInUser() when it comes to verifying user ids with GetUserProof? The user verification documentation uses LoggedInUser but the v51 SDK Reference says to use Get, so I'm not sure why the redundancy or the difference between the two methods?

[thecodexter]

Ah, looks like Get is used for collecting info on users other than your own, whereas LoggedInUser is only for your own user account on the headset. Definitely looks like you're following the verification process exactly as outlined in the documentation. The invalid userid requests all falling into the same number range is definitely suspicious...

[thecodexter · Accepted solution]

Turns out this was a JSON parsing issue. For other devs that run into this, Meta's documentation suggests using a ulong for user ID's, but JSON serializing for S2S Rest API's would often corrupt the end of the ID. Hence, Oculus server's will return the verify request as "invalid" since it was missing the entirety of the ID. We solved this by serializing the ID as a string, and passed that via S2S instead, which reduced most of the "invalid" requests. More on this here:

https://jsoneditoronline.org/indepth/parse/why-does-json-parse-corrupt-large-numbers/

[AronOlio]

Thanks @thecodexter!