CI Integration & OIDC Authentication
The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.
When you use Takumi Guard from CI linked to a Shisho Cloud organization, the CI job authenticates to Shisho Cloud as a bot with the ID token (OIDC token) issued to the job. The ID token is verified against the trust conditions of the bot, and on success a short-lived access token is issued. Package downloads made with that access token are recorded under your organization. No long-lived secrets need to be stored in your CI environment.
See the CI/CD section of each quickstart (for example, npm) for how to write the job.
Authentication Flow
The ID token contains information about the repository (the project, on GitLab) and the user that ran the job, and is signed by its issuer. Shisho Cloud's STS (Security Token Service) verifies the signature with the issuer's public keys and matches the token against the bot's trust conditions. If they match, it issues a short-lived access token for Takumi Guard.
Access Token
The access token carries the Shisho Cloud organization that downloads are attributed to, and information about the CI job. Takumi Guard verifies the token and records package downloads against the organization in the installation logs. The token expires after a short time, minimizing leak risk. The default access token lifetime is 30 minutes (configurable up to 24 hours).
Set it with the action's expires-in input on GitHub Actions, and with shishoctl's --expires-in-minutes option on GitLab CI/CD.
About Bot ID
Bot ID is not a secret. It is a public identifier that specifies the bot to sign in as, and can be written directly in workflow files or .gitlab-ci.yml. Authentication relies on verifying the ID token's signature and matching it against the trust conditions, so the Bot ID alone cannot obtain an access token.