GCP IAP JWT authentication #5599

New Issue

adam · 2025-12-29T19:29:59+01:00

adam commented

2025-12-29 19:29:59 +01:00

Originally created by @cova-fe on GitHub (Nov 3, 2021).

NetBox version

v3.0.8

Feature type

New functionality

Proposed functionality

Netbox should be able to use GCP IAP JWT token to create or authenticate users. IAP passes a signed token with email and ID of the user, so we can get those information and use them for the auth phase. I implemented a quick PoC and it is a few lines change.

Use case

Installation of netbox in GCP could make use of IAP authentication offered by GCP.

Database changes

No response

External dependencies

No response

Originally created by @cova-fe on GitHub (Nov 3, 2021). ### NetBox version v3.0.8 ### Feature type New functionality ### Proposed functionality Netbox should be able to use GCP IAP JWT token to create or authenticate users. IAP passes a signed token with email and ID of the user, so we can get those information and use them for the auth phase. I implemented a quick PoC and it is a few lines change. ### Use case Installation of netbox in GCP could make use of IAP authentication offered by GCP. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature pending closure status: under review labels 2025-12-29 19:29:59 +01:00

adam closed this issue

2025-12-29 19:29:59 +01:00

adam commented

2025-12-29 19:29:59 +01:00

@DanSheps commented on GitHub (Nov 3, 2021):

Duplicate of #7649

@DanSheps commented on GitHub (Nov 3, 2021): Duplicate of #7649

adam commented

2025-12-29 19:30:00 +01:00

@cova-fe commented on GitHub (Nov 3, 2021):

I'm not sure it is duplicate. What I propose is to use the header provided in IAP authentication that contains username and ID. No oidc, no external backends. It is just a different form of basic auth provided by a web browser. The #7649 refers to something else, more involved, afaics.

@cova-fe commented on GitHub (Nov 3, 2021): I'm not sure it is duplicate. What I propose is to use the header provided in IAP authentication that contains username and ID. No oidc, no external backends. It is just a different form of basic auth provided by a web browser. The #7649 refers to something else, more involved, afaics.

adam commented

2025-12-29 19:30:00 +01:00

@cova-fe commented on GitHub (Nov 3, 2021):

Basically:
50900d9959

@cova-fe commented on GitHub (Nov 3, 2021): Basically: https://github.com/cova-fe/netbox/commit/50900d99595065cfb6f6f08adb35fd90a7a37cdf

adam commented

2025-12-29 19:30:00 +01:00

@DanSheps commented on GitHub (Nov 3, 2021):

How is this different then what the social auth provides under the Google backend (More specifically, what does this get us that the social auth does not?)

@DanSheps commented on GitHub (Nov 3, 2021): How is this different then what the social auth provides under the Google backend (More specifically, what does this get us that the social auth does not?)

adam commented

2025-12-29 19:30:00 +01:00

@cova-fe commented on GitHub (Nov 3, 2021):

I guess that it provides less, actually. But it is a different situation. I'm using it to have a "basic auth" approach (requests will get an header that you can use and that's it). No need to set up callbacks and so forth. social auth is a bit more complex to setup.

@cova-fe commented on GitHub (Nov 3, 2021): I guess that it provides less, actually. But it is a different situation. I'm using it to have a "basic auth" approach (requests will get an header that you can use and that's it). No need to set up callbacks and so forth. social auth is a bit more complex to setup.

adam commented

2025-12-29 19:30:01 +01:00

@l1bra2013 commented on GitHub (Nov 5, 2021):

Per https://github.com/netbox-community/netbox/issues/7649#issuecomment-958048055 - this could probably be implemented using a user provided class implementing the Django auth + REST auth interfaces. Netbox would just need to provide sufficient configuration options to allow users to override commonly used authentication related options so that everyone doesn't have to modify the netbox code to incorporate the desired auth solution.

@l1bra2013 commented on GitHub (Nov 5, 2021): Per https://github.com/netbox-community/netbox/issues/7649#issuecomment-958048055 - this could probably be implemented using a user provided class implementing the Django auth + REST auth interfaces. Netbox would just need to provide sufficient configuration options to allow users to override commonly used authentication related options so that everyone doesn't have to modify the netbox code to incorporate the desired auth solution.

adam commented

2025-12-29 19:30:01 +01:00

@cova-fe commented on GitHub (Nov 5, 2021):

Avoiding to make changes in core code would be indeed great. However, the discussion seems to be more related to OIDC. To implement JWT auth I guess that the class will need to access http headers. Implementing REST and stuff like that wouldn't be a bit overkill for something that just checks an header and gets back username (that is already authenticated)? However, if you have an example of the direction you would like to follow, I'll be happy to have a look

@cova-fe commented on GitHub (Nov 5, 2021): Avoiding to make changes in core code would be indeed great. However, the discussion seems to be more related to OIDC. To implement JWT auth I guess that the class will need to access http headers. Implementing REST and stuff like that wouldn't be a bit overkill for something that just checks an header and gets back username (that is already authenticated)? However, if you have an example of the direction you would like to follow, I'll be happy to have a look

adam commented

2025-12-29 19:30:02 +01:00

@github-actions[bot] commented on GitHub (Jan 11, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jan 11, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:30:03 +01:00

@cova-fe commented on GitHub (Jan 12, 2022):

Before this issue gets closed, is there any change that it could be looked at? We are using this approach right now and moving to OIDC will cause some (unneeded) headaches :)

@cova-fe commented on GitHub (Jan 12, 2022): Before this issue gets closed, is there any change that it could be looked at? We are using this approach right now and moving to OIDC will cause some (unneeded) headaches :)

adam commented

2025-12-29 19:30:03 +01:00

@thatmattlove commented on GitHub (Feb 22, 2022):

I understand the intent here, and I think it's a good idea. That said, I don't like that this is GCP-specific. JWT is an open standard and we could easily work with them without relying on a GCP-specific dependency. I've used PyJWT in the past with great success. It seems to me the only thing we'd need to do differently is specific which header to read and use GCP's (or any provider's) JWKS endpoint for key validation. These could both be provided via configuration settings, and therefore be used with any authentication provider.

In practice, I think the way to implement this would be as another NetBox remote authentication backend. Something like netbox.authentication.JWTBackend, with some configuration settings like:

JWT_HEADER (string, required, specifies which HTTP header from which to read the JWT value)
JWT_JWKS_URL (string, optional, specifies the JWKS URL for public key validation, doesn't validate signing key by default)
JWT_AUDIENCE (string, optional, doesn't validate audience by default)
JWT_USERNAME_CLAIM (string, optional, uses email by default)

That's just off the top of my head, I'm sure there's room for improvement, should we decide to move forward with this.

Once implemented, it would work very much like netbox.authentication.RemoteUserBackend, the primary difference being that instead of only reading a specific HTTP header for the username attribute, additional validation is done, and additional attributes could be extracted. For example, netbox.authentication.RemoteUserBackend is likely susceptible to replay attacks, whereas proper JWT validation would mitigate that by ensuring the value passed from the server side is both signed by the expected party and valid at the time of use. Additional claims could also be extracted from the JWT, such as the user's full name, role, username (which wouldn't have to be their email), etc.

At any rate, I'd be happy to contribute to this if we decide to move forward with it.

@thatmattlove commented on GitHub (Feb 22, 2022): I understand the intent here, and I think it's a good idea. That said, I don't like that this is GCP-specific. [JWT is an open standard](https://jwt.io/) and we could easily work with them without relying on a GCP-specific dependency. I've used [PyJWT](https://github.com/jpadilla/pyjwt/) in the past with great success. It seems to me the only thing we'd need to do differently is specific which header to read and use [GCP's](https://cloud.google.com/iap/docs/signed-headers-howto#verifying_the_jwt_header) (or any provider's) JWKS endpoint for key validation. These could both be provided via configuration settings, and therefore be used with any authentication provider. In practice, I think the way to implement this would be as another [NetBox remote authentication backend](https://netbox.readthedocs.io/en/stable/administration/authentication/). Something like `netbox.authentication.JWTBackend`, with some configuration settings like: * `JWT_HEADER` (string, required, specifies which HTTP header from which to read the JWT value) * `JWT_JWKS_URL` (string, optional, specifies the [JWKS URL](https://pyjwt.readthedocs.io/en/stable/usage.html#retrieve-rsa-signing-keys-from-a-jwks-endpoint) for public key validation, doesn't validate signing key by default) * `JWT_AUDIENCE` (string, optional, doesn't validate `audience` by default) * `JWT_USERNAME_CLAIM` (string, optional, uses `email` by default) That's just off the top of my head, I'm sure there's room for improvement, should we decide to move forward with this. Once implemented, it would work very much like `netbox.authentication.RemoteUserBackend`, the primary difference being that instead of only reading a specific HTTP header for the username attribute, additional validation is done, and additional attributes could be extracted. For example, `netbox.authentication.RemoteUserBackend` is likely susceptible to replay attacks, whereas proper JWT validation would mitigate that by ensuring the value passed from the server side is both signed by the expected party and valid at the time of use. Additional claims could also be extracted from the JWT, such as the user's full name, role, username (which wouldn't _have_ to be their email), etc. At any rate, I'd be happy to contribute to this if we decide to move forward with it.

adam commented

2025-12-29 19:30:03 +01:00

@github-actions[bot] commented on GitHub (Apr 24, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 24, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:30:03 +01:00

@github-actions[bot] commented on GitHub (May 24, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (May 24, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#5599