OpenID Connect and ActiveState

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework. It provides a standardized and secure way for users to authenticate and authorize access to their information across different services, websites, and applications.

OIDC enables single sign-on (SSO) capabilities, letting users log in using their preferred identity provider (Google, Microsoft, PyPI, etc.) while providing client applications with verified user information through JSON Web Tokens (JWTs).

This simplifies the authentication process, enhances security, and promotes interoperability and automation by establishing a common identity layer that facilitates standardized user authentication across various online services and platforms, from the OIDC provider (ActiveState) to the third-party “client” applications or services (Google, Microsoft, PyPI, etc.)

Getting started with OICD

The following diagram provides an overview of how ActiveState’s OIDC provider integrates with client applications. The diagram below illustrates how a Python wheel is built and published to PyPI.org.

The OIDC identification and authorization steps happen within an isolated build process in the ActiveState build system so minimal user involvement occurs. The main steps of the OIDC process are:

• The build process requests an OIDC request token from ActiveState. This token contains claims about the user who started the build and other information about the build.
• The build process receives an OIDC request token from ActiveState.
• The build process submits the OIDC request token to the configured OIDC client to be validated— i.e. PyPI in the diagram above.
• Once the OIDC client successfully validates the claims presented in the token, it then provides a short-lived access token for the task’s duration.

Understanding the Token

An OIDC token is used to convey information about the authenticated user. When a user logs in using OpenID Connect, an ID token is issued by the identity provider (ActiveState) and sent to the client application (eg. Google, PyPI, etc.). This token contains information about the user, such as their identity, authentication identification, and potentially other claims depending on the scopes requested during authentication.

The OIDC token is typically signed and may be encrypted, ensuring its integrity and confidentiality during transmission. The client application can then use the information in the ID token to verify the user’s identity and make access control decisions. This helps create a secure and standardized way for applications to authenticate users and obtain their basic profile information.

The following information is conveyed in your token, the data format for each is shown in brackets

• Actor - ActiveState username of the user that triggered the build (string)
• ActorID - ActiveState user ID (UUID string)
• OrganizationURLName - Organization name (string)
• OrganizationID - Organization ID (UUID string)
• ProjectVisibility - The visibility status of the project. Possible values “public” or “private” (string)
• ProjectName - The project’s name (string)
• ProjectID - The project’s ID (UUID string)
• ProjectPath - The URL path of the project on the Platform, eg. “myorg/myproject” (string)
• Builder - Name of the internal builder that is publishing the token (string)
• IngredientName - Name of the ingredient being published (string)
• ArtifactID - The ID of the build ingredient being published (UUID string)

Example Subject claims

The ActiveState OIDC token will always have a Subject claim with the following format:

organization:[OrganizationID]:project[ProjectID]

If the OIDC receiving service allows configuration based on the token subject claim, you can use it to ensure only jobs from a specific Organization and Project are accepted.