Help
cancel
Showing results for 
Search instead for 
Did you mean: 
Copilot Lvl 2
Message 1 of 3

Using OAuth in App

Solved! Go to Solution.

I'm working on a Github App that'll use Github as authentication in it's own frontend (basically, if the user has access to the repo on Github, she'll have it in my app too), but haven't been able to quite figure out the user OAuth part.

 

I think I get the whole process of installing the app. I plan on not using the "Request user authorization (OAuth) during installation" feature as there's no need at installation time.

 

So, I figure when an anonymous user hits my app, it'll redirect to https://github.com/login/oauth/authorize and do the dance to get an access token, which I can then use to check access.

 

And then what? I gather that the App OAuth tokens have a shorter lifetime than the old OAuth tokens, so how do I handle renewal? Some point at using it to get an access token to an installation, but do I want that? Basically I just want to know if a user has read or write access to a given repo, and check periodically (depending on how long the session lives) if that's changed.

 

I belive that just redirecting the user to https://github.com/login/oauth/authorize whenever the token becomes invalid is a possible solution, but it seems rather heavy.

 

Alternatively, I could make a note of the users access to the repo and let that live for 24 hours, and simply reauth for each repository visited, but seems like a bit lazy.

 

2 Replies
Solution
Community Manager
Message 2 of 3

Re: Using OAuth in App

There's a few different ways of handling what you're describing. You essentially have two problems:

 

  1. You're authenticating a GitHub user
  2. You're checking if the GitHub user previously authenticated is authorized to access a given repository

 

From your description, it sounds like you're conflating the two when they're really rather separate concerns.

 

When authenticating, you're determining if the person accessing your app is who they say they are. But if someone with the right token accesses your app an hour later, a day later, or a month later doesn't mean they are the same person that did the original authentication. Someone could have pilfered the token. Someone could be sitting at the user's machine because they forgot to lock it. So most applications time out after a period of time ... whether 24 hours, a week, a month, etc ... and force the user to reauthenticate. This is done by throwing away the old authentication information and requesting a new one, exactly as you surmised. If the user has not revoked their authorization of your application on their account, then they'll quickly arrive back at your website without having to do anything more. You can see how this works using the website I set up using GitHub Authentication https://www.atom-tweaks.com by signing in, authorizing the app, then signing out and back in again.

 

As far as authorization goes though, the simplest way to check if a user is authorized to access a given repo is to attempt to access that repo for the user. If you get an error, then they're probably not authorized anymore.

 

To be clear, GitHub OAuth tokens do not expire by themselves. They can be revoked by the user but they will not "time out".

 

Let us know if you have more questions.

 

Copilot Lvl 2
Message 3 of 3

Re: Using OAuth in App

@lee-dohm 

I'm quite aware of the difference between authorization and authentication, but I might have been a bit terse in my question.

 

My confusion stems from Migrating OAuth Apps to GitHub Apps which states: "GitHub Apps use tokens that expire quickly, creating a much smaller window of time for compromised tokens to be in use.", which isn't particularly clear on whether that smaller window affects the OAuth token too. But I'm guessing that OAuth tokens work like they do form OAuth applications.

 

But I also think I was getting to fancy for my own good, was trying to avoid maintaining a session locally altogether.

 

Having a 24 hour lifetime on tokens in my app and requesting new seems like a good idea.

 

Thanks.