Separate Axis OIDC user identity claims from required access claims

Bottom line: Write separate identity and authorization expectations for Axis OIDC setup, then test each intended device role.

Source fact: documented behavior

The OpenID Connect Setup topic describes device login using the OpenID Connect authentication-code flow.

It says the remote-user claim identifies the logged-in user, while the required claim is validated for all requests.

The same setup description requires the configured admin, operator and viewer claims to be fulfilled.

Reading the documented settings does not return the client secret.

What the source does not establish

Do not treat an identity-provider login screen as acceptance of the device’s user identity or assigned role. Keep the intended identity provider, device model and interface support explicit. Avoid generalizing the example claims into values suitable for every organization. Do not place a live token or client secret in the article’s proposed test record.

Applicability questions

• Which claim should identify a person consistently on this device?
• What required claim must be present independently of the role mapping?
• Which test identities represent the intended admin, operator and viewer permissions?
• How will authorized administrators recover access if the proposed mapping fails?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends reviewing the device’s OIDC claim contract with the identity and device owners together.

1. Create a mapping sheet with separate rows for user identity, the required claim and each intended role. Put the organization’s approved expected values on that sheet using a protected process. Identify the source of each value and the person responsible for changing it. Do not copy the documentation’s example strings into a production design without that review.
2. Build a proposed test matrix with a correctly mapped identity, an identity missing the required claim and identities intended for different roles. For each case, write the expected device behavior before running the test. Evaluate the permitted device action as well as entry to the session. Keep the test within an approved pilot and preserve a supported administrative recovery path.
3. Read back the nonsecret settings and compare them with the mapping sheet. Verify secret handling through the approved credential-management process rather than expecting a settings response to reveal the secret. Investigate an unexpected role assignment at the claim-mapping boundary before changing unrelated network or application settings.

Verification and evidence

Keep a sanitized mapping sheet, exact device and software identity, relevant identity-provider configuration reference and the proposed case results. Record whether the intended user identity and permissions match the agreed design. Exclude full tokens, claim sets containing personal data and client secrets from broadly shared evidence.

Repeat the role and missing-claim cases after an identity-provider mapping change or device integration change. Have the responsible owners confirm the boundary between sign-in and permitted actions. These are proposed DSE tests; this article reports no completed authentication attempt or observed authorization result.

Official references

• OpenID Connect Setup — Axis Communications; official VAPIX documentation.

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.