Overview

Codecov’s Okta login adds an extra layer of security for larger organizations, allowing them to protect their private repositories on the Codecov UI behind authentication from Okta. A user is first required to log into Codecov through their source-control provider (i.e. GitHub, GitLab, Bitbucket etc).

📘

Okta support is limited to those organizations on the Codecov Enterprise plan or those organizations using Codecov's Dedicated Enterprise Cloud (DEC) offering. If you're looking to add Okta supported for your DEC instance, please visit this page instead.

Logged-in users who then try to view the private repos of their Organization will be prompted to sign into Okta in a banner on their Organization’s Repository List View:

Once the user authenticates, they will be able to access and see the private repos for the organization.

Setup and configuration

Codecov supports Okta through OpenID connect (OIDC).

Before you continue, make sure you have created an Okta app integration. Confirm that the Sign In Method is OIDC Connect and application type is Web Application.

Before moving forward, ensure you have Administrator privileges on Codecov.

Once you're ready with the Okta app integration, navigate to the Admin Settings page, which is only available to admins of organizations. Admins can view this tab under the "Org Settings" tab in the "Okta Access" section.

Organization admins can use this tab to input Okta credentials needed for authentication, and turn this feature on for all users. (note - non-admin members of the organization cannot view the Okta access tab)

Ensure you add the OKTA client ID, Client secret and Redirect URI (which you would find when setting up the app integration in Okta) and paste those values here.

At this point, you're ready to turn on Okta for your users.

An admin has 2 options here -

1. Enable Okta, without enforcing: In this case, users are recommended to authenticate via Okta, but they are not forced to, ensuring they do not lose any user experience.
2. Enforce Okta: In this case, users MUST authenticate via Okta. If they do not, they will lose access to private repositories.

When an org has “enabled” status, but without “enforced”, then users will still be able to see private repos for their organization. This temporary state allows organizations to gradually migrate users to Okta authentication, minimizing disruption to developers’ workflows and ensuring users are informed, while giving admins time to iron out any issues before fully enforcing Okta. The screenshot below shows what a user may see when the Organization has “enabled” but not “enforced”.

Once the migration has been communicated and tested, admins will have the ability to restrict private repositories from appearing for non-Okta authenticated users.

This is an example of what a user may see when the settings is both “enforced” and “enabled”:

Okta Log-in Flow for Users

Once an admin selects “Authenticate”, all users will be redirected to Okta to complete their sign in.

Okta then passes back the status of the login to Codecov to finish processing the sign-in. If the user signs in successfully, then the banner disappears and they should be able to see their private repos.

A user may potentially not be prompted for log in if they have already logged into their Okta account. In that case, Okta immediately redirects back to Codecov to finish the authentication process.