Authorization checks for PUT/DELETE?

[avidal]

I'm looking to deploy ncps internally at my company to bootstrap a bottom-up nix adoption. Part of this is that I want CI jobs to build flakes automatically and push them to ncps, but I don't want unauthenticated pushes open in general.

My first thought was to put an authorization proxy in front of ncps to perform these checks and then proxy to ncps (which is running with unauthenticated pushes).

But, maybe this is something the community in general would be in favor of?

There are several ways to add authorization, each with their own pros and cons. Briefly:

Opaque API keys / credentials: Simple to implement and understand, but requires a database or config file to track issued credentials. Expiration is problematic.

Self-minted JWTs: This is what attic does. An admin command can mint a JWT with specific access. Outside of the secret used to generate and sign the JWTs, no state is required on the server. While you can mint a JWT with an expiration, this complicates things: too short an expiration and you have to manually regenerate. Too long and a leaked token can operate with impunity.

OAuth consumer: Much more significant integration. Users have to configure ncps as a consumer in their oauth provider, and configure clients to authenticate. Requires a database to track clients.

OIDC consumer: While full OIDC is about as involved as OAuth, the relevant part here is the "identity token". The sweet spot if your clients can generate an identity token (which every(?) CI provider can issue). Largely stateless on the consumer (assuming they pre-fetch the signing keys). Since each "job" will generate a unique identity token, each token can have a very short expiration.

While I do think that there is value in self-minted JWTs, especially for eg, self-hosters that still want some authorization, I'd like to focus this discussion on OIDC.

OIDC

If you're unfamiliar, OIDC is "OpenID Connect". It's an open-standard authentication "protocol" built on top of OAuth 2.0. Where OAuth focuses on delegated authorization (minting tokens allowing service A to interact with service B on behalf of user U), OIDC is purely focused on identity and is fairly standard in the world of single sign on.

As mentioned above, while full OIDC can be as involved as OAuth, it doesn't have to be. In practical terms, if all you care about is the identity token, it's more correct to call this something like "federated authorization". However, many providers (such as GitHub and Gitlab) call this feature on their end OIDC, so it makes sense to call it OIDC here as well.

This system is designed around the "identity token". An identity token is issued by the provider (eg, your CI system). The identity token is a JWT that contains some data about the environment. For example, a GitHub Actions OIDC token will look similar to (docs):

{
  "jti": "example-id",
  "sub": "repo:octo-org/octo-repo:environment:prod",
  "aud": "https://github.com/octo-org",
  "ref": "refs/heads/main",
  "sha": "example-sha",
  "repository": "octo-org/octo-repo",
  "repository_owner": "octo-org",
  "actor_id": "12",
  "repository_id": "74",
  "repository_owner_id": "65",
  "run_id": "example-run-id",
  "run_number": "10",
  "run_attempt": "2",
  "actor": "octocat",
  "workflow": "example-workflow",
  "head_ref": "",
  "base_ref": "",
  "event_name": "workflow_dispatch",
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://token.actions.githubusercontent.com",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

A workflow can acquire this token by setting permissions.id-tokens: write and requesting a token through octokit or curl. See the linked docs for more.

Checking tokens

Every OIDC provider publishes a well-known URI that can be appended to the issuer (iss in the token above). In the Actions case, it's at https://token.actions.githubusercontent.com/.well-known/openid-configuration

This document has a jwks_uri that points to a "JSON Web Key Set" which defines the signing keys that the OIDC provider uses to sign tokens. This is the only state that a consuming service needs to have, and it can be fetched on startup.

A consumer of these identity tokens can use the key set to verify inbound tokens and then, provided the token is otherwise valid, match claims in the token against their own predefined policies.

Configuration example

Consider an oidc.policies block in the ncps config file. Each policy will list an issuer and an audience at a minimum and optionally a set of claims. Each claim must match. If a claim has multiple possible values, at least one of the values for that claim must match (AND across claims, OR within a claim).

Example:

oidc:
     policies:
       - issuer: "https://token.actions.githubusercontent.com"
         audience: "ncps.mydomain.tld"
         claims:
           sub:
             - "repo:myorg/*"
           ref:
             - "refs/heads/main"
             - "refs/tags/*"
       - issuer: "https://gitlab.internal.mydomain.tld"
         audience: "ncps.mydomain.tld"

So, with the above config a token from GitHub Actions would be allowed if:

• The audience matches
• The subject starts with "repo:myorg/" (ie, a workflow running on any repository in that org)
• The workflow is running on any tag OR on the main branch

Whereas any token issued by your internal GitLab instance intended for your ncps server (via audience) would be allowed.

[dosubot[bot]]

Hi @avidal! I'm Dosu and I’m helping the ncps team.

There is currently no native support or documentation for OIDC authorization or oidc.policies in ncps for PUT/DELETE operations. The official configuration only allows you to enable or disable PUT and DELETE verbs globally (for example, with allowPutVerb and allowDeleteVerb), but does not provide built-in mechanisms for fine-grained authorization or OIDC-based access control for these actions. The only authentication-related option mentioned is the use of a netrc file for upstream authentication, which is not tied to OIDC or claim-based policies reference.

If you need OIDC-based authorization, your approach of placing an authorization proxy in front of ncps is currently the most practical solution. This proxy would handle OIDC token validation and enforce your desired policies before forwarding requests to ncps, which would be running with PUT/DELETE enabled but not exposed directly.

There are no community discussions or documentation about OIDC authorization or similar features in ncps at this time. If you want to gauge community interest, you might consider sharing your use case and proposal in relevant forums or channels.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[avidal]

@dosu I'm aware, that's why I filed the discussion. The documentation suggests that if you have ideas or feature suggestions to open a discussion :)

[dosubot[bot]]

You're right—opening a discussion here is exactly what the documentation recommends for feature suggestions. Your approach is spot-on for proposing new ideas and gauging community interest. If you want to elaborate further or get feedback from maintainers and other users, this is the best place to do it. Let me know if you want to dig deeper into implementation details or explore alternatives!

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[kalbasit]

@avidal thanks for opening this discussion, I've also been meaning to figure a way to add authentication but I wanted to leave this for a bit later since it's still pretty early for this. With that said, I want to give your idea a fair assessment but I'm currently trying to solve #660, #805, #806, among others, and prep to release v0.8.5 and v0.9.0... Once I am done, I will get back to you. Expect a reply within the next week or so.

[avidal]

Of course, no worries. I have a branch on my fork that implements it including tests and documentation but it may be a bit large to ingest in one review. Early next week I'll expand this post to explain in more detail the proposal so it's a bit easier to reason about and discuss.

…

-- Alex Vidal

On Fri, Feb 13, 2026, 7:53 PM Wael Nasreddine ***@***.***> wrote: @avidal <https://github.com/avidal> thanks for opening this discussion, I've also been meaning to figure a way to add authentication but I wanted to leave this for a bit later since it's still pretty early for this. With that said, I want to give your idea a fair assessment but I'm currently trying to solve #660 <#660>, #805 <#805>, #806 <#806>, among others, and prep to release v0.8.5 and v0.9.0... Once I am done, I will get back to you. Expect a reply within the next week or so. — Reply to this email directly, view it on GitHub <#885 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABO3Z5UYO3J664L7YSSYN34LZ5YNAVCNFSM6AAAAACVCFRFEKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOBQGE3TONY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kalbasit]

Thank you, appreciate it.

Feel free to file a pr in draft as well.

[avidal]

Just filed #925

I also updated the OP here to be more descriptive.

[avidal]

Another option for the config that may be simpler to read is to nest oidc under a generic push-policies entry. Getting the shape of the config file correct now will make it simpler in the future to add more push policies without a breaking config schema change.

So, instead of:

cache:
  oidc:
       policies:
         - issuer: "https://token.actions.githubusercontent.com"
           audience: "ncps.mydomain.tld"
           claims:
             sub:
               - "repo:myorg/*"
             ref:
               - "refs/heads/main"
               - "refs/tags/*"
         - issuer: "https://gitlab.internal.mydomain.tld"
           audience: "ncps.mydomain.tld"

You have:

cache:
  push-policies:
    - type: oidc
      issuer: ...
      audience: ...
      claims: {}
    - type: oidc
       ...
    - type: other-future-type

[kalbasit]

I do like your second proposal:

cache:
  push-policies:
    - type: oidc
      issuer: ...
      audience: ...
      claims: {}
    - type: oidc
       ...
    - type: other-future-type

As you mentioned it scales well. It also allows the operator to choose which one they prefer over the other by making this an ordered list (future improvement ofc).

[avidal]

As an aside, I'm currently working on a separate flake that implements OIDC policies as a reverse proxy that I can stand in front of ncps so there's no urgency with this discussion (or the linked PR). Please don't feel the need to take it to satisfy my use case.

[kalbasit]

I appreciate your patience @avidal. I think I am very close to releasing v0.9 so I should get on this in a couple of days.

[kalbasit]

@avidal thank you for patiently waiting while I released v0.9 and a few more days to "brain reset --hard"...

This is a fantastic proposal. I completely agree with your assessment.

Relying on Workload Identity Federation (short-lived, provider-minted tokens) is vastly superior to managing static, long-lived API keys for CI/CD. While my default SRE instinct is often to push authentication to an edge proxy (like OAuth2-proxy), doing deep claim validation (like ensuring pushes only happen from refs/heads/main) at the ingress layer usually requires deploying OPA or writing custom Lua scripts. Baking this native, claim-based authorization directly into ncps provides a much cleaner, "batteries-included" experience.

As we move forward with the implementation, here are a few operational edge cases we need to ensure are covered:

1. JWKS Caching & Rate Limiting: Fetching the JWKS is stateless, but doing it on every request will result in rate limits from providers like GitHub. We need to ensure the JWKS is cached efficiently in memory.
2. Graceful Key Rotation: OIDC providers rotate their signing keys periodically. When ncps receives a JWT with an unrecognized Key ID (kid), it should attempt to re-fetch the JWKS to see if a rotation occurred before outright rejecting the token. If the cache is strictly time-based, we might experience push failures during rotation windows.
3. Method-Based Policies: Rather than hardcoding OIDC only for writes, we should design the feature so policies can apply specifically to GET, PUT, or DELETE requests, leveraging your excellent AND/OR logic. For instance, CI policies would need both GET and PUT (since Nix tries to pull the narinfo looking for a 404 before pushing). Conversely, developers could be required to authenticate via an internal provider (like Authentik) and have a policy that only allows GET requests.

Here is a quick example of what that configuration could look like in practice, let me know what you think:

oidc:
  policies:
    # CI Pipeline: Can read and push from the main branch
    - issuer: "https://token.actions.githubusercontent.com"
      audience: "ncps.mydomain.tld"
      methods: ["GET", "HEAD", "PUT"]
      claims:
        sub:
          - "repo:myorg/*"
        ref:
          - "refs/heads/main"
          - "refs/tags/*"

    # Local Developers: Can only read (pull) via internal SSO
    - issuer: "https://sso.internal.mydomain.tld/application/o/ncps/"
      audience: "ncps.mydomain.tld"
      methods: ["GET", "HEAD"]
      claims:
        groups:
          - "nix-developers"

I see you already have a draft PR open for this (#925). Could you update the PR and resolve any merge conflicts? Once it's ready, please trigger an automated review by commenting /gemini review on the PR. Keep iterating and addressing its comments until it's satisfied, and then we can take it from there!

[kalbasit]

@avidal are you still interested in making this happen?

[avidal]

Heya, apologies. I actually went with niks3 in our deployment because it fit our needs better.

Since I filed that PR I'm happy to address your comments if you're still interested in taking it in: just wanted to be clear that I personally no longer need it so I wouldn't really be testing it extensively in a real environment.