Revoking a GitHub OAuth token should revoke access
Categories
(Taskcluster :: UI, defect)
Tracking
(Not tracked)
People
(Reporter: dustin, Assigned: hassan)
Details
See https://bugzilla.mozilla.org/show_bug.cgi?id=1492666#c6 et seq.
STR:
- login with GitHub
- revoke OAuth token in GitHub UI
- observe that Taskcluster login continues unimpeded for 30 days
Comment 1•5 years ago
|
||
Would it be possible to support a "Sign out of all sessions" button or similar on the taskcluster side?
Reporter | ||
Comment 2•5 years ago
|
||
Not in the current implementation, as we don't store sessions anywhere.
One thought I had was to store the GitHub access_token in the TC token (the JWT) and verify that it's still valid every time the TC token is used (which is about once per 15 minutes). But I'm not sure if it's a good idea to reveal the access_token to the user.
Comment 3•5 years ago
|
||
One thought I had was to store the GitHub access_token in the TC token (the JWT) and verify that it's still valid every time the TC token is used (which is about once per 15 minutes). But I'm not sure if it's a good idea to reveal the access_token to the user.
Yeah, since the JWT is not encrypted I don't think any secrets should be included in it.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
So I guess the questions are:
- Is there a way to determine if a GitHub token has been revoked, without possession of that token?
- Should we encrypt the JWT?
- Is it worthwhile to add server-side storage for GitHub access tokens? Is the risk of token disclosure from that storage of concern
- Are there other solutions?
Comment 5•5 years ago
|
||
Is there a way to determine if a GitHub token has been revoked, without possession of that token?
The concern I have with relying on revoking tokens within Github is that it requires any user who wants to do a "sign me out on all devices" action to have a solid understanding of OAuth within Taskcluster + interacting with a service outside of Taskcluster. Basically, it feels like a bad UX for revocation.
Is it worthwhile to add server-side storage for GitHub access tokens? Is the risk of token disclosure from that storage of concern
If this is up for consideration, the additional question I would have is: Can we replace the use of JWT's with good 'ol fashioned session cookies? If so, the revocation story is a lot easier and simpler?
Assignee | ||
Comment 6•5 years ago
|
||
https://github.com/taskcluster/taskcluster/pull/1365 adds a server-side storage for GitHub access tokens which should resolve this bug.
Is there a way to determine if a GitHub token has been revoked, without possession of that token?
Once a Github token is revoked, calls to the GH API will start throwing errors. A user with a revoked access token won't be able to generate new creds when the client expires every 15 minutes.
Can we replace the use of JWT's with good 'ol fashioned session cookies?
This was done a while back in https://github.com/taskcluster/taskcluster/commit/cce41a8fde77a5ed9a46af9844f92970b944aaf9.
Reporter | ||
Comment 7•5 years ago
|
||
Nice! Win-Win-Win!
Assignee | ||
Comment 8•5 years ago
|
||
Resolved in https://github.com/taskcluster/taskcluster/commit/20bbcf3216805b0b8bc7a4aa10abea6430be0554.
Description
•