GitHub Integration Dilemma

[noredeen]

Okay guys so we've got a bit of a dilemma with our approach to authentication. Here is the situation:

First, I'll outline how GitHub expects we authenticate. We have 2 options with our GitHub authentication:

1. Recieve an access token from GitHub that does not have an expiry time. It would only expire if someone revokes it.
2. Reviece an access token from GitHub WITH an expiry time along with a refresh token. This access token expires after 8 hours and can be refreshed.

Also note that every authenticated user gets a maximum of 5000 requests per hour to the API.

My immediate reaction was to go with option 2 for better security (agree?). Although we are storing the user in our database, we may still need to ping the API for every request because if we don't, then if the user was kicked from the organization, they would have a brief window (until we reauthenticate via the API) to access the Codeprentice site like normal. What this means is that having our own JWT workflow (separate from GitHub's) is muddy, because it needs to be synced with the status of the GitHub tokens.

But the other issue is the API rate limit. If a user keeps refreshing a page that needs authentication and does so 5000 times, they will get rate limited assuming we authenticate on page load.

So the question is: do we solely rely on the tokens from GitHub and ping their API every time we want to authenticate? Or do we introduce our own JWTs to offload some of the traffic? Are there certain critical actions that we must always immediately reauthorize/reauthenticate directly with GitHub?

[DevinLeamy]

I believe that we should go with option two and I have three reasons for why.

1. The latter is cleaner. This approach is far less tethered to the GitHub API and utilizes tried and true authorization practices (namely JWT's).
2. The latter is faster and more practical. Sending an authentication request to GitHub every time a user wants to access a protected route is not practical and, for our purposed, should be regarded as overkill. When compared with the alternative, one request and the periodic verifications using JWT's, this approach would also be much slower.
3. The latter is just as safe. The argument that users will have a brief window of unauthorized access after being kicked from the organization is only true if we allow users to have this window of access. Given that the kicking should be a function implemented into the platform, one possible solution would be to black-list the JWT refresh token associated with the kicked user (assuming that they have logged in) upon being kicked.

[noredeen]

Yes, I'm leaning towards that too. That said, should we at all reauthorize with the GitHub API after a user has logged in via the web flow? Do you think it's enough to authenticate with GitHub the first time and then have our authentication system pick up from there?

[DevinLeamy]

Yes, I believe that it is enough. If we treat the GitHub authentication as if it were a tradition username password authentication system (which from my understanding we are) then this single login approach is the standard, trusted, convention.

At the end of the day, if we encounter a big problem with security down the road we can always change our system.