I’ve never used Nightbot or created an extension for Nightbot, so I’m lacking some context for my answers. This answer isn’t an exhaustive look at OAuth. I would recommend reading up on it if you want more information. Grab your favorite drink and get ready for a lot of words. 
Let’s start with the Client-ID requirement. The only time you have to send the Client-ID is if you’re calling https://api.twitch.tv/kraken/. I looked through a few of your APIs and only see a handful that do this: Give, Kill, UpTime, Lick, Love, etc. Those will require that you add the Client-ID header. If you combine those into a single API, you can use one Client-ID. Otherwise, use multiple.
Next, let’s talk about OAuth authorization and authentication. Authentication is verifying the user is who they claim to be. In our case, they have a Twitch account and are logged in. Easy peasy. Authorization is different altogether. This is the user giving your application permission to take an action on their behalf. An example would be that your application wants to post on their channel feed. You can’t do that without the user’s explicit permission to the channel_feed_edit scope. The user is basically giving you a way to impersonate them to take certain actions. Those actions are governed by scopes in OAuth. You will also see these in the Twitch API documentation. When you send a user through an OAuth flow (either implicit grant or authorization code in Twitch’s case), your application will declare which scopes are important to it and request access to those depending on what it needs to do. The user has full rights to say yes or no to that request.
Now, when the user authorizes your application, a code or token is generated depending on what you request. You’ll get a code for the authorization code flow and an access token on the implicit grant flow. With the authorization code, you will have to make another Twitch API call to get the OAuth token. With token, you just get the token directly. You might ask why you would the flow with the extra call. There is a larger explanation that I won’t get into, but the short version is that each flow is suited for different environments and each flow has different security concerns. Again, if you read up on OAuth, you’ll read about these flows.
How do you get the tokens or codes? Well, that’s where the redirect_uri comes into play. When a user authorizes your application, the OAuth flow redirects the user back to your redirect_uri. This should point to a web page that you own since it will contain information to get an OAuth token for that user. In the authorization code flow, your redirect URI will be:
https://[your registered redirect URI]/?code=[CODE]
You must then parse that URL parameter in order to exchange it for an OAuth token. In the implicit grant flow, your redirect URI will be:
https://[your registered redirect URI]/#access_token=[an access token]&scope=[authorized scopes]
You must parse out the access_token URL fragment, which is your OAuth token. Once you have a token, your application must send that value as the Authorization HTTP header when making an API call.
Having said all that (hope you’re still with me), you may not need an OAuth token. This all depends on which Twitch APIs your application is using. If the Twitch API has a required scope, you need a token. An example would be the /feed/:channel/posts endpoint. If the Twitch API doesn’t have a required scope, you don’t need a token. An example would be the /channels/:channel endpoint. In all cases, you need a Client-ID.
Finally, I’ll answer a few questions directly:
…what all extra files do I need to upload to my website since they have to authorize my app?
The only extra file you would need is the file at redirect_uri to grab the authorization code or OAuth token. Again, this is only if you actually need OAuth.
Is there a way to run the API so that way whoever is using it doesn’t have to authorize my app?
No. The only way they don’t have to authorize is if the APIs you’re using have no required scopes.
I hope this helps!