[PR #3159] [management] enable optional zitadel configuration of a PAT #19482

Open
opened 2026-08-05 05:06:04 -04:00 by saavagebueno · 0 comments
Owner

Original Pull Request: https://github.com/netbirdio/netbird/pull/3159

State: closed
Merged: Yes


for service user via the ExtraConfig fields.

re-opening PR #2661 after pull/rebase

Describe your changes

I'm sure this one is a little spicier of a take than my last PR to merge in some extra logging. During my struggle to get the recent zitadel working with netbird, I added the ability for netbird to just use a PAT to work around it while I investigated further.

Since the JWT and PAT both use the same mechanism to pass the token in the authorization header, the existing struct for JWTToken can be used and the authentication step short-circuited by supplying a long lasting AccessToken.

My current configuration looks somewhat like this:

    "IdpManagerConfig": {
        "ManagerType": "zitadel",
        "ClientConfig": {
           ...
        },
        "ExtraConfig": {
            "ManagementEndpoint": "https://zitadel-domain/management/v1",
            "PAT": "*****************************"
        },

As zitadel operators for more than just netbird, we have PATs for multiple different project service accounts across other orgs that integrate with it, and would prefer to use a PAT to simplify our security procedures too.

I'm not sure if this is the best end state for user experience as I rushed to implement something that worked in a fire, but figured this would be a good starting place to open the conversation.

Checklist

  • Is it a bug fix
  • Is a typo/documentation fix
  • Is a feature enhancement
  • It is a refactor
  • Created tests that fail without the change (if possible)
  • Extended the README / documentation, if necessary
**Original Pull Request:** https://github.com/netbirdio/netbird/pull/3159 **State:** closed **Merged:** Yes --- for service user via the ExtraConfig fields. re-opening PR #2661 after pull/rebase ## Describe your changes I'm sure this one is a little spicier of a take than my last PR to merge in some extra logging. During my struggle to get the recent zitadel working with netbird, I added the ability for netbird to just use a PAT to work around it while I investigated further. Since the JWT and PAT both use the same mechanism to pass the token in the authorization header, the existing struct for `JWTToken` can be used and the authentication step short-circuited by supplying a long lasting `AccessToken`. My current configuration looks somewhat like this: ```json "IdpManagerConfig": { "ManagerType": "zitadel", "ClientConfig": { ... }, "ExtraConfig": { "ManagementEndpoint": "https://zitadel-domain/management/v1", "PAT": "*****************************" }, ``` As zitadel operators for more than just netbird, we have PATs for multiple different project service accounts across other orgs that integrate with it, and would prefer to use a PAT to simplify our security procedures too. I'm not sure if this is the best end state for user experience as I rushed to implement something that worked in a fire, but figured this would be a good starting place to open the conversation. ## Issue ticket number and link ### Checklist - [ ] Is it a bug fix - [ ] Is a typo/documentation fix - [x] Is a feature enhancement - [ ] It is a refactor - [ ] Created tests that fail without the change (if possible) - [ ] Extended the README / documentation, if necessary
saavagebueno added the pull-request label 2026-08-05 05:06:04 -04:00
Sign in to join this conversation.
No Label pull-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#19482