Github Authentication flow is very annoying - Please find a better solution / How can I make my token stick around for the day?

[LutzLange]

trafficstars

WGE release:

• 0.8.0-rc.1

I do understand the need for the auth flow with Github. But the timeout is too low for me. I need to authenticate multiple times and it is annoying. Could we not save the GitHubToken somewhere and reuse it?

Alternatively How could I increase the timeout?

[davidstauffer]

Agreed. We should work in a more permanent way. We should explore to stoke a Personal access token as a secret and bind it to a user. @foot

[LutzLange]

Could we revisit this? There has not been any improvement as far as I can see.

[bigkevmcd]

We could simply store it in a cookie for say 8 hours (configurable) ?

[bigkevmcd]

The risk of storing secrets in-cluster is that if stolen, they can be very powerful.

[foot]

We do store it in a cookie but it seems by default Github expires these device tokens very quickly https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps#device-flow

There is mention of the user code expiring in 15minutes on that page, but thats the code that we use to get an actual token. The actual token I can't see expiry info about.

Maybe we could be doing a refresh or passing in diff params somewhere to extend the expiry.

The other bigger option here would be to support github app oauth as we do with gitlab. Which is more of a config hassle but worth it quite quickly I think.

[bigkevmcd]

We will get a refresh token with the oauth token, we can use that to refresh...

[foot]

👍 , I think I have not understood this system very well, we also expire the JWT storing the token in 15 minutes 🤦

https://github.com/weaveworks/weave-gitops/blob/0c5b6aa5507c08b9582dbc37c24d603f6b34516a/pkg/server/server.go#L138-L139

So we could bump that up to 8 hours (configurable) for sure.

[makkes]

+1 , I think I have not understood this system very well, we also expire the JWT storing the token in 15 minutes facepalm

https://github.com/weaveworks/weave-gitops/blob/0c5b6aa5507c08b9582dbc37c24d603f6b34516a/pkg/server/server.go#L138-L139

So we could bump that up to 8 hours (configurable) for sure.

As a general security measure JWT tokens, especially those stored in browser cookies, should have a very short lifetime so 15 minutes is reasonable. The reason is that if the token is extracted by an adversary the window of opportunity to do anything harmful is very short. The second reason is that a JWT token can't be revoked so e.g. a deactivation of the user doesn't have effect without further server-side measures such as a revokation list which in turn kind of defeats the purpose of client-side token storage.

[foot]

cc @jpellizzari you touched the bitbucket auth stuff recently, would it be tricky to add github-app / (clientid/clientsecret) support? I guess falling back to the device-auth that we currently have if no app is configured or something.

[lasomethingsomething]

Did we make progress on this?

[jpellizzari]

cc @jpellizzari you touched the bitbucket auth stuff recently, would it be tricky to add github-app / (clientid/clientsecret) support? I guess falling back to the device-auth that we currently have if no app is configured or something.

At the time of implementing, GH did not have a good "untrusted client" method for OAuth. For GH, we would need a predictable callback URL, which we cannot guarantee. We also used the Device flow for CLI OAuth, which I'm not sure is relevant anymore?

Did we make progress on this?

Not to my knowledge.