{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/separate-axis-oidc-user-identity-claims-from-required-access-claims/", "item": { "id": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/", "slug": "separate-axis-oidc-user-identity-claims-from-required-access-claims", "url": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims.md", "json": "https://update.dsesecurity.com/api/v1/posts/separate-axis-oidc-user-identity-claims-from-required-access-claims/" }, "title": "Separate Axis OIDC user identity claims from required access claims", "summary": "Axis OIDC setup distinguishes remote-user identity, a required claim and role claims. Review those mappings separately instead of treating successful sign-in as proof of the intended device permissions.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T00:10:25+00:00", "modified_at": "2026-10-29T00:10:34+00:00", "reviewed_on": "2026-10-28", "reading_minutes": 3, "word_count": 503, "potentially_affected": "Axis devices exposing the documented OpenID Connect Setup interface; confirm support and the installed API/software scope before applying the proposed checks.", "dse_recommendation": "DSE recommends reviewing the device’s OIDC claim contract with the identity and device owners together.", "primary_source": { "name": "Axis Communications — OpenID Connect Setup", "url": "https://developer.axis.com/vapix/device-configuration/openid-connect-setup/", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source fact: documented behavior

\n

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

\n

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

\n

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

\n

Reading the documented settings does not return the client secret.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n

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

\n
    \n
  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. \n
  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. \n
  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.
    4. \n
\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

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

\n", "content_text": "Bottom line: Write separate identity and authorization expectations for Axis OIDC setup, then test each intended device role.\nSource fact: documented behavior\nThe OpenID Connect Setup topic describes device login using the OpenID Connect authentication-code flow.\nIt says the remote-user claim identifies the logged-in user, while the required claim is validated for all requests.\nThe same setup description requires the configured admin, operator and viewer claims to be fulfilled.\nReading the documented settings does not return the client secret.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nWhich claim should identify a person consistently on this device?\nWhat required claim must be present independently of the role mapping?\nWhich test identities represent the intended admin, operator and viewer permissions?\nHow will authorized administrators recover access if the proposed mapping fails?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends reviewing the device’s OIDC claim contract with the identity and device owners together.\n\nCreate 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.\nBuild 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.\nRead 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.\n\nVerification and evidence\nKeep 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.\nRepeat 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.\nOfficial references\n\nOpenID Connect Setup — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: Write separate identity and authorization expectations for Axis OIDC setup, then test each intended device role.\n\n## Source fact: documented behavior\n\nThe [OpenID Connect Setup](https://developer.axis.com/vapix/device-configuration/openid-connect-setup/) topic describes device login using the OpenID Connect authentication-code flow.\n\nIt says the remote-user claim identifies the logged-in user, while the required claim is validated for all requests.\n\nThe same setup description requires the configured admin, operator and viewer claims to be fulfilled.\n\nReading the documented settings does not return the client secret.\n\n## What the source does not establish\n\nDo 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.\n\n## Applicability questions\n\n- Which claim should identify a person consistently on this device?\n\n- What required claim must be present independently of the role mapping?\n\n- Which test identities represent the intended admin, operator and viewer permissions?\n\n- How will authorized administrators recover access if the proposed mapping fails?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends reviewing the device’s OIDC claim contract with the identity and device owners together.\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Verification and evidence\n\nKeep 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.\n\nRepeat 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.\n\n## Official references\n\n- [OpenID Connect Setup](https://developer.axis.com/vapix/device-configuration/openid-connect-setup/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/", "url": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Separate Axis OIDC user identity claims from required access claims", "item": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/#article", "identifier": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/", "url": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/", "headline": "Separate Axis OIDC user identity claims from required access claims", "description": "Axis OIDC setup distinguishes remote-user identity, a required claim and role claims.", "abstract": "Axis OIDC setup distinguishes remote-user identity, a required claim and role claims. Review those mappings separately instead of treating successful sign-in as proof of the intended device permissions.", "articleBody": "Bottom line: Write separate identity and authorization expectations for Axis OIDC setup, then test each intended device role.\nSource fact: documented behavior\nThe OpenID Connect Setup topic describes device login using the OpenID Connect authentication-code flow.\nIt says the remote-user claim identifies the logged-in user, while the required claim is validated for all requests.\nThe same setup description requires the configured admin, operator and viewer claims to be fulfilled.\nReading the documented settings does not return the client secret.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nWhich claim should identify a person consistently on this device?\nWhat required claim must be present independently of the role mapping?\nWhich test identities represent the intended admin, operator and viewer permissions?\nHow will authorized administrators recover access if the proposed mapping fails?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends reviewing the device’s OIDC claim contract with the identity and device owners together.\n\nCreate 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.\nBuild 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.\nRead 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.\n\nVerification and evidence\nKeep 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.\nRepeat 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.\nOfficial references\n\nOpenID Connect Setup — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T00:10:25+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/separate-axis-oidc-user-identity-claims-from-required-access-claims/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Separate Axis OIDC user identity claims from required access claims" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 503, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — OpenID Connect Setup", "url": "https://developer.axis.com/vapix/device-configuration/openid-connect-setup/" } } ] } }