Peopleix · OAuth Scopes

Peopleix OAuth Scopes

OAuth 2.0 probed

Peopleix uses OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (e.g. client-credentials or role-based authorization) rather than per-scope consent.

This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.

CompanyHRPeople AnalyticsPeople IntelligenceConversation IntelligenceHuman ResourcesWorkforce AnalyticsAIMCPGermany

Scopes: 0 Flows: Method: probed

Scopes (0)

Peopleix implements OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (client-credentials or role-based authorization) rather than per-scope consent.

peopleIX publishes no OpenAPI and no scopes/permissions reference page, so these scopes come straight from the anonymously-served OAuth metadata on the application host. Two facts matter here and are recorded rather than smoothed over: the AUTHORIZATION SERVER advertises only the two generic identity scopes below, and the PROTECTED RESOURCE (the MCP server) advertises an EMPTY scopes_supported array — meaning peopleIX exposes no per-tool or per-dataset scoping to a connecting agent. For a platform whose subject matter is employee-level HR data, the absence of a scope surface is the finding, not an omission in our capture.

📄 Provider scope reference:

Source

OAuth Scopes

generated: '2026-08-14'
method: probed
source: https://app.peopleix.com/.well-known/oauth-authorization-server and https://app.peopleix.com/.well-known/oauth-protected-resource/mcp
note: >-
  peopleIX publishes no OpenAPI and no scopes/permissions reference page, so these
  scopes come straight from the anonymously-served OAuth metadata on the application
  host. Two facts matter here and are recorded rather than smoothed over: the
  AUTHORIZATION SERVER advertises only the two generic identity scopes below, and the
  PROTECTED RESOURCE (the MCP server) advertises an EMPTY scopes_supported array —
  meaning peopleIX exposes no per-tool or per-dataset scoping to a connecting agent.
  For a platform whose subject matter is employee-level HR data, the absence of a
  scope surface is the finding, not an omission in our capture.
docs: null
authorization_server: https://app.peopleix.com
scopes:
- name: openid
  description: >-
    Standard OpenID Connect scope requesting an ID token identifying the authenticated
    peopleIX user. Claims available: sub, iss, aud, exp, iat, email, name, org_id.
  source: oauth-authorization-server scopes_supported
- name: offline_access
  description: >-
    Requests a refresh token so an MCP client can maintain access without
    re-prompting the user.
  source: oauth-authorization-server scopes_supported
resource_scopes:
  resource: https://app.peopleix.com/mcp
  scopes: []
  note: >-
    scopes_supported is an explicitly empty array in the RFC 9728 protected-resource
    metadata. Access to the MCP tool surface therefore appears to be all-or-nothing
    against the authenticated user's org membership (org_id claim), not scope-limited.
scope_count: 2
x-evidence:
  fetched: '2026-08-14'
  urls:
  - url: https://app.peopleix.com/.well-known/oauth-authorization-server
    status: 200
  - url: https://app.peopleix.com/.well-known/oauth-protected-resource/mcp
    status: 200