Just to clarify, you cannot use the Client Secret, the private key is still required. But the OAuth Client ID is now recommended to be used as a substitute to the numeric app ID for github.com, and probably GitHub Enterprise Server 3.14+

We just shipped support for passing the client ID to Octokit's app authentication strategy:
https://github.com/octokit/auth-app.js/releases/tag/v7.1.0

@cloudshiftchris edit title to clarify that support is sought for using clientId instead of appId?

@gr2m are you saying this is already supported via octokit/auth-app.js#606 ?

@gr2m are you saying this is already supported via octokit/auth-app.js#606 ?

yes

So does this mean that we can pass in client ID instead of app ID, and this issue can be closed... or? @gr2m

I think this should be closed. I have used clientId in place of appId

we should document the fact that client ID can be used as an alternative to the app ID, then we can close this issue

A somewhat self-documenting way to do this would be to add a new client-id parameter:

with:
  client-id: <clientID>

Then app-id could be deprecated and removed in a future version.

The problem with that approach is that app-id would no longer be required, which helps with Intellisense and with catching bugs today. I agree though that eventually we should support client-id instead of app-id, to align with GitHub's recommendation.

For now, I suggest we merge #251

For the migration from app-id to client-id, I suggest the following

1. Once we are ready to release v3 with other breaking changes, Update v2 add client-id as input, remove required from app-id, and mark it as deprecated
2. In v3, add a custom error if the app-id is set to help with the upgrade.

But we just released a breaking version, I'd give us some time to see what other things we need to change over the next few months.

Makes sense--do you want to create a tracking issue for "v3 breaking changes list" so that you don't lose track of this one?