Request an access token failed with a 406 Not Acceptable error

[root-io]

octokit.request('POST https://github.com/login/oauth/access_token', {
      client_id: 'xxx',
      client_secret: 'xxx',
      code: 'xxx'
    });

but got:

{ HttpError
    at response.text.then.message (/usr/src/app/node_modules/@octokit/request/dist-node/index.js:66:23)
    at process._tickCallback (internal/process/next_tick.js:68:7)
  name: 'HttpError',
  status: 406,
  headers:
   { 'cache-control': 'no-cache',
     connection: 'close',
     'content-security-policy':
      'default-src \'none\'; base-uri \'self\'; block-all-mixed-content; connect-src \'self\' uploads.github.com www.githubstatus.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com wss://live.github.com; font-src github.githubassets.com; form-action \'self\' github.com gist.github.com; frame-ancestors \'none\'; frame-src render.githubusercontent.com; img-src \'self\' data: github.githubassets.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com; manifest-src \'self\'; media-src \'none\'; script-src github.githubassets.com; style-src \'unsafe-inline\' github.githubassets.com',
     'content-type': 'text/html',
     date: 'Mon, 05 Aug 2019 09:45:17 GMT',
     'expect-ct':
      'max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"',
     'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
     server: 'GitHub.com',
     'set-cookie':
      'has_recent_activity=1; path=/; expires=Mon, 05 Aug 2019 10:45:17 -0000, ignored_unsupported_browser_notice=false; path=/',
     status: '406 Not Acceptable',
     'strict-transport-security': 'max-age=31536000; includeSubdomains; preload',
     'transfer-encoding': 'chunked',
     vary: 'X-PJAX',
     'x-content-type-options': 'nosniff',
     'x-frame-options': 'deny',
     'x-github-request-id': 'D9D4:CE13:12F09C0:1D5FA50:5D47FAAD',
     'x-request-id': '238cdf6e-28ac-4d06-8a9f-00ff204ceedc',
     'x-xss-protection': '1; mode=block' },
  request:
   { method: 'POST',
     url: 'https://github.com/login/oauth/access_token',
     headers:
      { accept: 'application/vnd.github.v3+json',
        'user-agent': 'octokit.js/16.28.7 Node.js/10.16.0 (Linux 4.9; x64)',
        'content-type': 'application/json; charset=utf-8' },
     body:
      '{"client_id":"xxx","client_secret":"xxx","code":"xxx"}',
     request: { hook: [Function: bound bound register] } } }

Not sure what I am doing wrong

[gr2m]

I've just run into this myself while working on https://github.com/octokit/auth-oauth-app.js (would appreciate if you could give it a try!)

https://github.com/login/oauth/access_token is not part of the REST API so it does not know what to do with the accept: 'application/vnd.github.v3+json' header which @octokit/request sets by default.

Could you pass a custom accept header to the request?

    octokit.request('POST https://github.com/login/oauth/access_token', {
      client_id: 'xxx',
      client_secret: 'xxx',
      code: 'xxx',
      headers: {
        accept: "application/json"
      }
    });

That should work

[root-io]

Your solution works like a charm, thanks !

[klichukb]

Has anyone contacted support about this?
https://developer.github.com/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/
Why do they have a warning and a "preview" header requirement above the "/login/oauth/access_token" endpoint?

[gr2m]

Expiring user tokens are currently in beta and subject to change, see https://developer.github.com/changes/2020-04-30-expiring-user-to-server-access-tokens-for-github-apps/

[klichukb]

@gr2m do you know about the regular access_tokens (say, without expiration), like in the original question of the issue? My point is, i'm confused that
the login/oauth/access_token endpoint here is marked as
"The API may change without advance notice during the preview period", states that it requires the "preview" accept value, however that doesn't seem to be true.

[gr2m]

Ah I see, good point, I'll ping the docs team to clarify. The preview is only needed to use the new token refresh functionality

[klichukb]

@gr2m thanks for clarification!! Does it mean that overall using Github App (with its granular permissions) via the standard OAuth flow is not a preview feature and can be considered suitable for production?
(as opposed to for example using installation IDs which are marked as preview feature)

[gr2m]

As far as I understand it, yes. Only the expiring tokens are new, the rest has been around for years

[klichukb]

For sake of everyone else googling this, I contacted support:
Using OAuth flow with Github App is not a preview feature, documentation at this point has a bug stating that it requires a preview header. It is stable, ready for production and won't be changed without prior notice.

[gr2m]

The docs are being updated, the preview message will be removed. Thanks again Bogdan!

[rachmari]

@klichukb

Has anyone contacted support about this? https://developer.github.com/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/
Why do they have a warning and a "preview" header requirement above the "/login/oauth/access_token" endpoint?

This is a defect, and you should see updated docs in the next 24 hours! The machine-man preview is only needed when using the GET /user/installations and GET /user/installations/:installation_id/repositories endpoints listed on that page.

As far as I understand it, yes. Only the expiring tokens are new, the rest has been around for years

Yes, that is correct. Only expiring tokens are in beta. Everything else is production-ready. We are trying to clarify in our docs what the beta applies to. This is great feedback to hear and we'll use it to improve the experience around documenting beta features.

[klichukb]

Great, it's fixed now - thank you for quick reaction! 👍

[klichukb]

Since we're on this.. (a bit different question about the related documentation as well)

Is it expected that the Beta feature (expiration) is enabled by default now when creating an app? If this is intended, maybe its worth putting a "Beta" label near the flag or having it off by default to be consistent with the "Opt-in" strategy for existing apps?

[rachmari]

@klichukb thank you for the feedback! I've passed this feedback on to our engineering team to consider. 🙇‍♂️