Closed meteorlxy closed 4 years ago
Maybe use PKCE?
@jonasfranz
As far as I know (limited though), PKCE is not supported by most of the platforms.
For now we can use Implicit Grant Type for this on GitLab and Bitbucket (GitHub does not support it) #22
BTW, if gitea can support Implicit Grant Type or PKCE, we can try to make use of it for sure 😄
@meteorlxy gitea supports pkce
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Any updates on gatekeeper? Do you recommend https://github.com/Rob--W/cors-anywhere instead? If so, are there some simple instructions to setting it up?
What is the issue?
Currently, if we are using GitHub, we have to hard-code
clientSecret
in our js/html files, which has potential risks.There are already some discussions about that:
In brief, hard-coding
clientSecret
will cause some security concerns.Does it really matter?
Yes but no.
Impersonate you website?
Attackers may copy your
clientId
andclientSecret
, but the platform will check theredirect_uri
as well.That means that, attackers can't mislead users to their fake sites with your
clientId
(unless something like DNS hijacking, which might be another story), so they can't get user'scode
on their sites with yourclientSecret
.In addition, it's more convenient for "attackers" to create a new OAuth App than copy yours, and the target of the "attackers" is the platform but not your website.
From another perspective, your website is "static" and have nothing worth to be attacked...
So you don't need to worry about that.
Impersonate you OAuth App?
Github: OAuth Authorizations API - for example, if attackers get your client secret, they can revoke a grant of an user, so the user have to authorize your app again when he try to login on your website next time. It's possible if someone is aiming at your website, but it might not be so critical.
In brief, it does have security concerns, but not critical. This is why gitment and gitalk didn't fix that.
Plans of enhancement
But it's still an issue.
Currently:
clientSecret
is only used for gettingaccess_token
access_token
does not support CORS, so we have to use proxy for nowTo completely solve this issue, you can use a private proxy to get
access_token
, and store yourclientSecret
in the proxy, rather than in your client code.An existing project is https://github.com/prose/gatekeeper, which can be deployed on Heroku/Azure by yourself easily. But it's not compatible with our current proxy option
So Vssue is planning to: