Support Client ID as an alternative input to Client Secret

[cloudshiftchris]

GitHub now recommends using the clientId instead of the appId/privateKey

Augment the options to allow clientId/clientSecret, validating that either this pair or appId/privateKey are provided, and pass these options along in the call to createAppAuth.

[gr2m]

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

[joebowbeer]

@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]

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

yes

[BeyondEvil]

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

[joebowbeer]

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

[gr2m]

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

[jeffwidman]

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.

[gr2m]

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.

[jeffwidman]

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?