💥 Fix oauth name & username mixup

[coyotte508]

• Change format of userInfo returned, use raw response from the hub
• Make it work in non-browser context (user needs to pass additional args) - useful for automated tests
• Add automated tests

Due to breaking change, will need major version upgrade

In the end I decided to go with the raw response, without transforming it.

Because a lot of the fields are standard openID connect fields (eg preferred_username), and to make the developer's job easier when they search docs or they already have other OpenID integrations in their app.

Even if it's snake_case while the rest of the API is camelCase.

[Wauplin]

@coyotte508 FYI I saw the review request. I'm taking the advantage to recreate (-ish) the same on the Python side to better understand the PR and then I'll comment back here

[Wauplin]

Looks good to me! Better to have an approval from a JS dev though ^^

Is the expectation that using localStorage will fix all cookie-related issues? Also just to be sure, if someone adds a "Sign in with HF" button in their Space using this, only the front-end will be able to make calls on behalf of the user, right?

(EDIT: I took heavy inspiration from this PR and especially the test part for huggingface/huggingface_hub#2684)

[Wauplin]

how of curiosity, is there any reason to do a POST instead of a GET (or vice-versa) here?

[coyotte508]

The POST is to grant the oauth app the authorization. GET works for subsequent calls, but not the first time ever for the user <-> app tuple

[coyotte508]

Is the expectation that using localStorage will fix all cookie-related issues?

At least currently it doesn't suffer the same issues as cookie

Just to be clear, it's already been implemented for a long time, but some fields were mixed up...

Also just to be sure, if someone adds a "Sign in with HF" button in their Space using this, only the front-end will be able to make calls on behalf of the user, right?

yes (unless the frontend passes the oauth token to the backend...)