Google consent screen always asking for permission grant (View Cloud Identity Groups) everytime we connect about openvpn-auth-oauth2 HOT 6 CLOSED

Hi!

Searching for this issue it seems 60 minutes is the default expiration for the Google access token.

In that context, it wont matter. Only the OpenVPN server is authorized to disconnect the client. I guess, the OpenVPN default setting reneg-sec 3600 initiate a re-authentication. It's a default value on client and server, changing the value on server is not sufficient. openvpn-auth-oauth2 doesn't care about the expire date of the access token.

approval_prompt=force

It problem is a bit on Google side. approval_prompt=force is mandatory, otherwise the Google OIDC Server doesn't issue a refresh token. The refresh token is required for a non-interactive session refresh.

A workaround would be oauth2.refresh.validate-user=false. this enables a session refresh on openvpn-auth-oauth2 without asking for a refresh token. (which should not ask for consent anymore). In conclusion, the also skips the user verification step on Google side.

You will also find some information here: https://github.com/jkroepke/openvpn-auth-oauth2/wiki/Configuration#non-interactive-session-refresh

from openvpn-auth-oauth2.

Thanks for the help!

We have set the reneg-sec to 12 hours.
I guess we could even disable it (reneg-sec 0) as we use AES-256-GCM (https://community.openvpn.net/openvpn/wiki/SWEET32) but OpenVPN doesn't start when reneg is infinite due to another options being enabled. No problem on this side, as 12 hours is enough for us.

Regarding the consent screen, we have tried setting validate-user=false but we see no changes as we keep permissions being requested every time we log-in.
Maybe there's another option misconfigured, but I see no hints on the OpenVPN logs appart from
[IP_REDACTED]:60956 TLS: Username/Password authentication deferred for username ''

We use certificate authentication, issued by local RSA and with common_name being the email of the Google side.

I will keep playing with options, including entirely disabling the refreshes.

from openvpn-auth-oauth2.

Update: Seems we made a mistake when configuring the validate-user entry.

I can confirm that, when correctly set, it works as you predicted:

refresh: enabled: true expires: 8h0m0s use-session-id: true validate-user: false

Do you know what are the security implications of setting it to false? Thanks

from openvpn-auth-oauth2.

Do you know what are the security implications of setting it to false? Thanks

Sure. If set to false, openvpn-auth-oauth2 assume the user is still valid (e.g enabled, in correct groups) and continue the session.

If a employee opens a VPN session and you disable the account after 3 hours, he is still able to access the VPN for 9 hours.

If validate-user=true, then openvpn-auth-oauth2 caches the refresh token from the initial session start and use the refresh token to refresh the session. Normally, the IDP would deny the refresh, if the users gets deactivated.

from openvpn-auth-oauth2.

I think this is a minor drawback that compensates the improvement in the end-user experience.

I guess it's just then a question of restarting the openvpn-auth-oauth2 service every time we deactive a user in the IDP, or somehow edit the token cache if it is file based. We will check whether the token cache is in memory or not, deactivate a test user, etc... to adjust that procedure.

Thanks again for the support!

from openvpn-auth-oauth2.

it's in-memory ;-)

Your are welcome.

May ask myself how I could improve the documentation here that it's more understandable for the next one?

from openvpn-auth-oauth2.