Open vlad902 opened 9 years ago
Can you elaborate?
Are you talking about if an application is compromised after a token has been revoked?
No, I'm talking about an application flow that revokes it's own access after authorization. It 1) gets authorized, 2) performs its operation, and 3) revokes it's own access (not just the session token.) This doesn't take much convenience away from users as they simply need to click 'Authorize' the next time they choose to use the application.
You might ask why completely revoking access to a user account is more desirable than simply revoking a session token, the answer is that defensive developers would like to ensure that the myriad of ways that an application could be compromised (DNS hijacking, SQLi leading to RCE, or even for poorly designed applications a combination of XSS or CSRF) would not impact their users.
As an example, I reported this issue in the DO install button: https://github.com/seven1m/do-install-button/issues/7
The DO install button could enable malicious websites to launch VMs under the control of the malicious website. If it were possible to revoke access, a defensive developer could use that as another step to prevent themselves from being vulnerable to such an attack.
I'm basing a project on the DO install button and noticed this vulnerability, while I plan to fix the obvious CSRF bug I'd also love to be able to actually protect my users by revoking my own access once I'm done launching a VM.
This issue is very annoying. It is not only for the security issues - if I want to allow my users to switch to another DO account, they have to revoke access at DO; I cannot do it via the API. The oauth/revoke endpoint simply does not do anything. The access is not revoked. => this should be marked as BUG, not enhancement.
https://developers.digitalocean.com/documentation/oauth/#revoke-token-flow
I've just been trying to implement this also to allow users to switch accounts and I assumed I was calling the revoke URL incorrectly.
Please look at this.
This is a problem for me, too
Currently, the OAuth API allows an application revoke a specific access token; however, the application continues to remain authorized for the user account. Insecure applications could potentially allow malicious individuals leveraging XSS/CSRF vulnerabilities (or access to the application's server) to perform action's to a victim's account on behalf of the application. It should be possible to safe guard an application's user by either exposing an endpoint to revoke the application's access explicitly or setting a timeout period with the authorize request.