We’re excited to announce that you can now perform git operations on git repositories hosted in Oracle Cloud Infrastructure (OCI) DevOps with session token-based authentication and existing other OCI authentication mechanisms, including SSH tokens, API keys, instance authentication, and resource principals

Are you looking for a way to access OCI code repositories once or for a short time? Are you afraid of using your long-lived access tokens because of security concerns? Session token-based authentication for OCI DevOps Git Operations has the answer. This blog outlines the high-level steps with sample outputs to use session token-based authentication.

Why session tokens?

Session tokens enable you to access the code repositories for short-term or one-time use. These tokens become invalid after some fixed timeout period (Typically 1 hour). So, you can use session tokens wherever you want short-term secured access and you’re concerned about creating soft keys like SSH tokens and API keys that can be accidentally accessible to a malicious user.

You can continue to use the SSH tokens and API keys, which are long-lived and valid until you rotate them from your OCI account. You can also configure multiple auth mechanisms simultaneously by creating multiple CLI config profiles.

Now let’s see how you can perform git operations with session token-based authentication.

Step 1: Getting the session token

OCI’s Command Line Interface (CLI) is the prerequisite to get the session token. The OCI CLI is a small-footprint tool that you can use on its own or with the Oracle Cloud Console to complete OCI tasks. You can install the OCI CLI you haven’t done it already.

To use token-based authentication for the OCI CLI on a computer with a web browser, use the following steps:

  1. In the CLI, run the following command:

    oci session authenticate

  2. Choose your region, which launches a web browser.

    Enter a region by index or name(e.g.
1: af-johannesburg-1, 2: ap-chiyoda-1, 3: ap-chuncheon-1, 4: ap-dcc-canberra-1, 5: ap-hyderabad-1,
6: ap-ibaraki-1, 7: ap-melbourne-1, 8: ap-mumbai-1, 9: ap-osaka-1, 10: ap-seoul-1,
11: ap-singapore-1, 12: ap-sydney-1, 13: ap-tokyo-1, 14: ca-montreal-1, 15: ca-toronto-1,
16: eu-amsterdam-1, 17: eu-dcc-dublin-1, 18: eu-dcc-dublin-2, 19: eu-dcc-milan-1, 20: eu-dcc-milan-2,
21: eu-dcc-rating-1, 22: eu-dcc-rating-2, 23: eu-frankfurt-1, 24: eu-madrid-1, 25: eu-marseille-1,
26: eu-milan-1, 27: eu-paris-1, 28: eu-stockholm-1, 29: eu-zurich-1, 30: il-jerusalem-1,
31: me-abudhabi-1, 32: me-dcc-muscat-1, 33: me-dubai-1, 34: me-jeddah-1, 35: mx-queretaro-1,
36: sa-santiago-1, 37: sa-saopaulo-1, 38: sa-vinhedo-1, 39: uk-cardiff-1, 40: uk-gov-cardiff-1,
41: uk-gov-london-1, 42: uk-london-1, 43: us-ashburn-1, 44: us-chicago-1, 45: us-gov-ashburn-1,
46: us-gov-chicago-1, 47: us-gov-phoenix-1, 48: us-langley-1, 49: us-luke-1, 50: us-phoenix-1,
51: us-sanjose-1): 43

    If the browser doesn’t open automatically, you can open the browser with the URL shown on CLI after the command output.

  3. In the browser, enter your user credentials. This authentication information is saved to the .config file. Ensure that the user principal you add has permission to clone DevOps code repositories through DevOps code repository policies.

  4. After successful configuration, you get the following output:

    Completed browser authentication process!
Config written to: ~/.oci/config
Try out your newly created session credentials with the following example command:
oci iam region list --config-file ~/.oci/config --profile DEFAULT --auth security_token

  5. You can also run the sample command from your output to check if it works.

If you already have configured the CLI, it asks for the profile name. You can choose ‘DEFAULT’ to override the existing one or type a new profile name if you want to retain existing configurations. Read more about CLI profiles in the documentation.

Step 2: Performing git operations

Now we can use git commands with the newly created session token. This one-time operation happens during while cloning. After cloning, you can use other git commands like pull, fetch, and push as usual.

Run the following command to clone the git repository. This command works on all Linux-based terminals. Before running it, replace <REPO_URL> with your repo URL and change DEFAULT if you have chosen a different profile name. For how to get your URL, see the documentation.

git clone https://SESSION_TOKEN:$(cat ~/.oci/sessions/DEFAULT/token)@<REPO_URL>

The command clones the git repo and sets the upstream origin to the REPO_URL with that specific SESSION_TOKEN.

Reauthentication: If your token expires

The session token is valid for approximately one hour. After that, all the git operations with git repo interactions, such as fetch, pull, and push, fail until you reauthenticate and update the upstream origin URL with a new session token. Repeat this process whenever the token expires.

  1. Follow the steps from the “Getting the session token” section.

  2. Run the following command from your cloned directory to update the upstream URL with the new token. This command works on all Linux-based terminals. Before running it, replace <REPO_URL> with your repo URL and change DEFAULT if you have chosen a different profile name. For how to get your URL, see the documentation.

    git remote set-url origin https://SESSION_TOKEN:$(cat ~/.oci/sessions/DEFAULT/token)@<REPO_URL>

Conclusion

In this post, we showed how you can perform git operations on OCI DevOps-hosted git repositories with session token-based authentication. You can continue to use OCI authentication mechanisms, such as SSH tokens, API keys, instance authentication, and resource principals. Because the session token is short-lived and gets invalidated after a short time, we recommend using session token-based authentication to prevent unnecessary extended access to malicious users.

If you’re new to Oracle Cloud Infrastructure, you can create your Oracle Cloud Free Tier to get acquainted.

For more information, see the following resources: