# Configure Google OAuth2 Authentication

To enable Google OAuth2, you must register a new application with Google.

## Create Google OAuth2 Keys

In the Google environment, follow these steps:

1. Navigate to the [Google Credentials](https://console.cloud.google.com/projectselector2/apis/credentials?) page.

2. Click **Create credentials > OAuth client ID**.

3. Select the **Web application** type.

4. Enter **Name** , such as Kloudfuse.

5. Enter URL of the kloudfuse installation in the **Authorized JavaScript Origins**.
   
   Example: `kloudfuse.yourcompany.com`

6. Enter URL that has the `/oauth2/callback` of the kloudfuse in the **Authorized redirect URIs**.
   
   Example: `kloudfuse.yourcompany.com/oauth2/callback`

7. Click **Create**.

8. Copy the **Client ID** and **Client Secret** from the `OAuth Client` modal.
   
   Save it for next steps.

## Enable Google Auth in Kloudfuse

### Option 1: Use Client ID and Secret

In your `custom-values.yaml` file, add google client ID and secret:

```yaml
kfuse-auth:
  oauth2-proxy:
    config:
      clientID: "REPLACE_CLIENT_ID"
      clientSecret: "REPLACE_CLIENT_SECRET"
```

### Option 2: Use Kubernetes secrets

In the kfuse namespace, create 2 kubernetes secrets:

1. Create a secret called `kfuse-auth-users` as mentioned here.

2. Create a new kubernetes secret, `kfuse-auth-users`; you can also update an existing secret.

Use the output of `cat users.txt| base64` as the value of `users.txt` entry in the secret.

Use the `edit` command if editing an existing secret.

Edit Secret
   
   ```console
   kubectl edit secret kfuse-auth-users
   ```

Create kubernetes secret kfuse-auth-users

```yaml
apiVersion: v1
data:
  users.txt: |-
    <base64-encoded-value-from-above>
kind: Secret
metadata:
  name: kfuse-auth-users
type: Opaque
```

1. Create a new kubernetes secret, `kfuse-auth-google`.

Use base64-encoded values for client id and client secret from [`kfuse-auth-users`](https://docs.kloudfuse.com/platform/3.5.0/sso-google/#secret-kfuse-auth-users) secret.

To generate cookie secret, see the OAuth2 Proxy documentation for [Generating a Cookie Secret](https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview/#generating-a-cookie-secret).

Create kubernetes secret kfuse-auth-google

```yaml
apiVersion: v1
data:
     client-id: <base 64 encoded google client id>
     client-secret: <base 64 encoded google client secret>
     cookie-secret: <base 64 encoded random value>
kind: Secret
metadata:
      name: kfuse-auth-google
type: Opaque
```

2. Include the two secrets in your `custom-values.yaml` file:

Add secrets to `custom-values.yaml`

```yaml
kfuse-auth:
     oauth2-proxy:
       config:
         existingSecret: "kfuse-auth-google"
       htpasswdFile:
         existingSecret: "kfuse-auth-users"
```

## Configure Cookies

For some applications that must adhere to external compliance requirements, you may have to use custom configuration for cookies.

|     |     |
| --- | --- |
|  | Cookie refresh functionality described in this section only works with OIDC-based authentication (such as Google OAuth2). It is not compatible with SAML-based authentication setups.

|     |     |
| --- | --- |
|  | If after applying the cookie configuration settings you are not seeing the expected refresh behavior, try adding `offline_access` to the OAuth2 scope. This scope allows the system to obtain refresh tokens from the identity provider. Note that some providers (like Google) do not require this scope, while others may need it. For Okta configuration with `offline_access`, see [Add offline_access Scope](https://docs.kloudfuse.com/platform/3.5.0/sso-okta/#offline-access). |

### Concepts

- **cookie-expire**: Total lifetime of the session cookie. If the user shows no activity after this duration, the system logs the user out. The user must subsequently re-authenticate.
- **cookie-refresh**: Interval at which OAuth2-Proxy automatically uses the IdP refresh token to renew the session cookie, and resets its TTL. This gets triggered by an active HTTP request, such as a click, navigation, or AJAX.
- **Activity**: Any HTTP request sent to the protected App — page navigation, AJAX call, or link click. Passive actions like hovering or viewing the page qualify as `Inactivity` or `Idle` time.
- **Behavior**: On each valid request, if the session cookie is older than `cookie-refresh`, OAuth2-Proxy calls the IdP to get a fresh access token, and re-issues the cookie with a full `cookie-expire` TTL. If no requests occur within the `cookie-expire` window, the session expires.

### Idle Timeout/Inactivity Configuration for Kloudfuse OAuth2-Proxy

For example, to meet [HIPPA](https://docs.kloudfuse.com/platform/3.5.0/glossary/#hippa) standards, you must configure the `cookie-expiry` and `cookie-refresh` parameters for logout and other workflows.

To control automatic logout after a period of user inactivity, or idle timeout, tune the `cookie-expire` and `cookie-refresh` settings in your custom YAML.

To set the idle timeout, follow these steps:

1. Choose the idle timeout period. This is the `cookie-expire` value.
2. Set the refresh interval to a value shorter than the `cookie-expire` you chose in the previous step. This becomes your `cookie-refresh` value.

Log out after 30 minutes, renew session every 5 minutes

To log users out after 30 minutes of inactivity, and to renew their session every 5 minutes when active, add the following code to your custom `yaml` file:

```yaml
kfuse-auth:
  oauth2-proxy:
    extraArgs:
      cookie-expire: "30m" (1)
      cookie-refresh: "5m" (2)
```

|     |     |
| --- | --- |
| **1** | `cookie-expire`: "30m" means that the session lasts up to 30 minutes without activity. |
| **2** | `cookie-refresh`: "5m" means that for each request older than 5 minutes, OAuth2-Proxy will renew the cookie. |

|     |     |
| --- | --- |
|  | SSO/SAML flows<br>Refresh tokens must be valid; if the IdP’s refresh token TTL is shorter than `cookie-expiry`, sessions end earlier than the time limit set by `cookie-expiry`.<br>Basic Auth<br>No OAuth refresh flow. After reaching `cookie-expiry` or `cookie-refresh` values, whichever is shorter time, the user gets logged out, and must sign in again.