Authorization

When entities (Console User, Integration Key, or IoT Device) access the IDaaS & IAM APIs, a strict authentication and authorization process is enforced. These entities must first authenticate with the Authorization Server. Upon successful authentication, they are granted a JWT access token. Entities then use this token to access the APIs.

WARNING

In the latest version, we no longer include all claims directly within the access token. Instead, developers are expected to use the ./authz endpoint to retrieve a separate JWT containing the full set of claims associated with that access token.

Please note that the JWT returned from the ./authz endpoint is intended strictly for authorization checks and cannot be used as a primary access token.

Authorization Claims in JWT Token

{
  "sub": "iotuser",
  "aud": "six-iam-xzy",
  "nbf": 1728618455,
  "role": [
    {
      "ROLE_iam-iot-product-key": [
        "iam_config_read",
        "iam_key_create",
        "iam_keys_read",
        "iam_key_update"
      ]
    },
    {
      "ROLE_iam-iot-app-edit": [
        "iam_app_update",
        "iam_app_create",
        "iam_app__client__link_remove"
      ]
    },
    {
      "ROLE_iam-iot-product-edit": [
        "iam_iot__product_update",
        "iam_iot__product__props_create",
        "iam_iot__product__topic_delete",
        "iam_iot__product__topic_create",
        "iam_iot__product_create",
        "iam_iot__product_delete"
      ]
    },
    {
      "ROLE_iam-iot-device": [
        "iam_iot__analysis_deviceMsg",
        "iam_iot__device__mqttmsgs_read",
        "iam_iot__device__statuses_read",
        "iam_iot__device__info_acls",
        "iam_iot__device__info_bindings",
        "iam_iot__device_bind",
        "iam_iot__analysis_activeDevice"
      ]
    },
    {
      "ROLE_iam-iot-app-read": [
        "iam_app__clients_read",
        "iam_app_read",
        "iam_app__users_read",
        "iam_apps_read"
      ]
    },
    {
      "ROLE_iam-iot-product-read": [
        "iam_iot__product_read",
        "iam_iot__products_read"
      ]
    },
    {
      "ROLE_iam-device": [
        "iam_device_read",
        "iam_devices_read",
        "iam_device_registration",
        "iam_device__guid_read",
        "iam_device_provision"
      ]
    },
    {
      "ROLE_iam-iot-config-read": [
        "iam_iot__config_read"
      ]
    },
    {
      "ROLE_iam-iot-client-read": [
        "iam_clients_read"
      ]
    },
    {
      "ROLE_iam-iot-client-edit": [
        "iam_client__app_create",
        "iam_client_create",
        "iam_client_update"
      ]
    }
  ],
  "org": {
    "level": 0,
    "orgId": "0a2a0093-8bf6-1dda-818b-f64e02080000"
  },
  "openId": "0a2a0091-8bf6-1cf7-818b-f65f90820000",
  "scope": [
    "openid",
    "profile"
  ],
  "iss": "https://iam.shuhenglianchang.com",
  "exp": 1728618755,
  "iat": 1728618455,
  "jti": "38a615ab-d748-4de4-838e-38f031a657cd"
}

Authorization Enforcement

For all APIs intended to be accessed only by authenticated entities, a multi-layered authorization process is enforced. Beyond the primary verification of the access token's authenticity via JWK, the Resource Server performs secondary validation. This ensures the accessing entity has been granted the necessary permissions, assigned the required attributes, or both, before access to the specific resource is permitted.

TIP

Refer to the sections below for details on permission-based (Authorization Enforced on Permissions) or attribute-based (Authorization Enforced on Attributes) authorization checks.

There is also a Resource Hierarchy concept for the platform APIs and resources. Resources related to SiX IDaaS & IAM are typically associated with a specific "Organization."

Access is restricted so that only an entity within the same organization—or a superior (parent) organization—can access these resources. For example, an "admin user" in a superior organization can seamlessly manage resources located within its sub-organizations.

TIP

Refer to the Resource Hierarchy Concept section below for a detailed breakdown.

Resource Hierarchy Concept

SiX IDaaS & IAM platform resources, such as Identity Applications (directories), are managed within a specific Organization or Workspace. Access is governed by a hierarchical model: only entities (Console Users, Integration Keys, or IoT Devices) allocated to the same organization—or a superior organization in the hierarchy—can access these resources.

When developing your own APIs using the SiX IDaaS & IAM multi-tenancy framework, you can implement this same hierarchical concept. For more information, please refer to Develop your own APIs based on IAM.

Authorization Enforced on Permissions

The Resource Server enforces authorization checks for specific APIs based on permissions. Syntactically, the authorization requirements follow the sample below:

The invoker need have the authorities 
hasPermission(#clientPrimaryId, 'client-app', 'create') or hasPermission(#clientPrimaryId, 'TargetClient', 'ALL') 
to call the API.

TIP

You can see the authorization information on API Doc as below.

Authorization Enforced on Attributes

The Resource Server enforces authorization checks for specific APIs based on entity attributes. Syntactically, the authorization requirements follow the sample below:

The invoker need have the authorities 
@attributeMethodSecurity.matchAttributeValue(authentication, #productId, 'six_iot_product') and @attributeMethodSecuritymatchAttributeValue(authentication, 'device_reg', 'purpose') 
to call the API.

TIP

You can see the authorization information on API Doc as below.

Platform API Access

The SiX IDaaS & IAM platform categorizes its APIs into the functional areas listed below. Follow the links to access detailed documentation and interactively test the endpoints:

• IDaaS & IAM APIs – Core services for identity management, authentication, and token exchange.
• IDaaS & IAM Mgt APIs – Administrative APIs for managing organizations, tenants, and system configurations.
• Device APIs – IoT-specific APIs for device registration, provisioning, and secure communication.