GitHub is now going away from OAuth apps and has introduced GitHub Apps (GHA). The main feature for us is that the GHA auth tokens can be set to expire, currently after 8 hours. There is a refresh token that can be used to re-issue auth tokens without user interaction which is currently valid for 6 months. The actual API mechanism is identical, you still use oauth/authorize which returns a code which is passed to oauth/access_token API to obtain auth_token, but that request also returns the refresh_token and scope is empty, because the permissions are defined at the point of creating/registering the app.
Note that GitHub Apps are entirely optional at this point.
Possible action items:
Document the use of GitHub Apps without any change to the way RCloud works. Note that if "Expire user authorization tokens" is disabled in the GHA (at registration - cannot be changed later) this gives exactly the same functionality as OAuth apps. However, the main point of GHA is to allow for token expiry, so if expiry is enabled, it allows RCloud authentication with GitHub only for 8 hours (since access_token expires after that time). Also, we may need to document the required permissions when registering the app (gists + email) which used to be governed by the scope from RCloud side, but now must be setup by the owner of the app - which makes a lot more sense.
(TBD: are we required to send empty scope= or will GH be ok with us supplying the scope as we do today?).
Check if auth_token expiry has any UI impact. Ideally, it should lead to a re-direct to GitHub to authorize. Note that this is in principle also possible with OAuth apps if the user revoked the grant. The tricky part here is if the expiry is only recognized in some internal operations (like notebook update). As far as SKS is concerned the browser-side token is still valid as its validity is not tied to the GH token.
Store refresh tokens such that we can automatically request a new auth token after it expired. The API entry point is still oauth/access_token, but instead of code= it uses grant_type=refresh_token&refresh_token=. Probably the best way to go about it is to store both tokens in SessionKeyServer and use access_token first, if expired, refresh using the refresh token and update SKS entry. There should be no change to SKS necessary (unless we want to SKS to mirror/monitor the expiry times).
NB: whether OAA or GHA is involved can be auto-detected from the oauth/access_token response by the presence of refresh_token in the response.
The benefit of the GHA API is that is given more flexibility to the deployment site with GitHub back-end to control the duration of authentication.
GitHub is now going away from OAuth apps and has introduced GitHub Apps (GHA). The main feature for us is that the GHA auth tokens can be set to expire, currently after 8 hours. There is a refresh token that can be used to re-issue auth tokens without user interaction which is currently valid for 6 months. The actual API mechanism is identical, you still use
oauth/authorizewhich returns a code which is passed tooauth/access_tokenAPI to obtainauth_token, but that request also returns therefresh_tokenandscopeis empty, because the permissions are defined at the point of creating/registering the app.Note that GitHub Apps are entirely optional at this point.
Possible action items:
Document the use of GitHub Apps without any change to the way RCloud works. Note that if "Expire user authorization tokens" is disabled in the GHA (at registration - cannot be changed later) this gives exactly the same functionality as OAuth apps. However, the main point of GHA is to allow for token expiry, so if expiry is enabled, it allows RCloud authentication with GitHub only for 8 hours (since
access_tokenexpires after that time). Also, we may need to document the required permissions when registering the app (gists + email) which used to be governed by thescopefrom RCloud side, but now must be setup by the owner of the app - which makes a lot more sense. (TBD: are we required to send emptyscope=or will GH be ok with us supplying the scope as we do today?).Check if
auth_tokenexpiry has any UI impact. Ideally, it should lead to a re-direct to GitHub to authorize. Note that this is in principle also possible with OAuth apps if the user revoked the grant. The tricky part here is if the expiry is only recognized in some internal operations (like notebook update). As far as SKS is concerned the browser-side token is still valid as its validity is not tied to the GH token.Store refresh tokens such that we can automatically request a new auth token after it expired. The API entry point is still
oauth/access_token, but instead ofcode=it usesgrant_type=refresh_token&refresh_token=. Probably the best way to go about it is to store both tokens in SessionKeyServer and useaccess_tokenfirst, if expired, refresh using the refresh token and update SKS entry. There should be no change to SKS necessary (unless we want to SKS to mirror/monitor the expiry times). NB: whether OAA or GHA is involved can be auto-detected from theoauth/access_tokenresponse by the presence ofrefresh_tokenin the response.The benefit of the GHA API is that is given more flexibility to the deployment site with GitHub back-end to control the duration of authentication.