Kufu Authentication

generated: '2026-07-19'
method: searched
source: https://developer.smarthr.jp/api/about_api
description: >-
  Authentication profile for the SmartHR API. The published Swagger 2.0
  document (openapi/kufu-smarthr-openapi.json) declares NO securityDefinitions,
  so this profile could not be derived from the spec — it was read from the
  developer documentation. SmartHR uses long-lived access tokens issued by a
  tenant administrator from the SmartHR admin dashboard. There is no OAuth 2.0
  authorization server and no dynamic client registration; consequently there
  is no OAuth scopes artifact for this provider.

docs: https://developer.smarthr.jp/api/about_api
token_issuance: https://support.smarthr.jp/ja/help/articles/360026266033/

spec_declares_security: false
spec_gap: >-
  The Swagger document omits securityDefinitions entirely even though every
  operation requires an access token. This is a governance gap worth flagging
  to the provider — see overlays/kufu-smarthr-overlay.yaml, which patches the
  scheme back in without mutating the original spec.

schemes:
  - name: bearerToken
    type: http
    scheme: bearer
    in: header
    parameter: Authorization
    format: 'Authorization: Bearer ACCESS_TOKEN'
    primary: true
    description: >-
      The documented and preferred method. The access token is generated by a
      tenant administrator in the SmartHR admin dashboard.

  - name: basicAuth
    type: http
    scheme: basic
    in: header
    parameter: Authorization
    description: >-
      HTTP Basic authentication is also accepted, with the access token
      supplied as the credential.

oauth2: false
openid_connect: false
mutual_tls: false
scopes: none — access tokens are not scope-delimited via OAuth

tenancy:
  model: subdomain-per-tenant
  base_url_pattern: https://{subdomain}.smarthr.jp/api
  sandbox_url_pattern: https://{subdomain}.daruma.space/api
  description: >-
    Every request is bound to a tenant by the host subdomain; the access token
    is issued within, and valid only for, that tenant.

related_sso:
  description: >-
    Distinct from API authentication: the API exposes operations to manage SAML
    SSO accounts for end users (getV1UsersIdSamlUser, postV1UsersIdSamlUser,
    patchV1UsersIdSamlUserEnable, patchV1UsersIdSamlUserDisable). These govern
    how humans sign in to SmartHR, not how API clients authenticate.