Aignostics · Authentication Profile

Aignostics Authentication

Authentication

Aignostics secures its APIs with oauth2 across 1 declared security scheme, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode and deviceCode flow(s).

CompanyArtificial IntelligenceMachine-LearningHealthHealthcareLife SciencesPathologyMedical ImagingDigital PathologyOncologyBiotechnologyResearchGermany
Methods: oauth2 Schemes: 1 OAuth flows: authorizationCode, deviceCode API key in:

Security Schemes

OAuth2AuthorizationCodeBearer oauth2
· in: header () · flows: authorizationCode, deviceCode

Source

Authentication Profile

Raw ↑
generated: '2026-09-14'
method: searched
source: >-
  https://aignostics.readthedocs.io/en/latest/get_started_api.html,
  https://aignostics-platform.eu.auth0.com/.well-known/openid-configuration,
  openapi/aignostics-platform-api-openapi.json
docs: https://aignostics.readthedocs.io/en/latest/get_started_api.html
api: Aignostics Platform API
summary:
  types:
  - oauth2
  oauth2_flows:
  - authorizationCode
  - deviceCode
  anonymous_access: false
  api_keys: false
  statement: >-
    "There is no anonymous access and no organization-wide API key." Every call carries a per-user
    OAuth bearer token; entitlement is evaluated against the user's organization.
identity_provider:
  vendor: Auth0
  tenant: aignostics-platform.eu.auth0.com
  region: EU
  issuer: https://aignostics-platform.eu.auth0.com/
  discovery: https://aignostics-platform.eu.auth0.com/.well-known/openid-configuration
  jwks_uri: https://aignostics-platform.eu.auth0.com/.well-known/jwks.json
  enterprise_sso: true
  mfa: mandatory
  note: >-
    The SDK README states enterprise SSO through Auth0 with mandatory two-factor authentication on
    all user accounts, and SDK v1.3.0 added an organization parameter to the OAuth flow.
schemes:
- name: OAuth2AuthorizationCodeBearer
  type: oauth2
  in: header
  header: 'Authorization: Bearer {access_token}'
  flows:
  - flow: authorizationCode
    authorizationUrl: https://aignostics-platform.eu.auth0.com/authorize
    tokenUrl: https://aignostics-platform.eu.auth0.com/oauth/token
    scopes: 0
    note: >-
      Declared in the OpenAPI with an EMPTY scopes object. See scopes/aignostics-scopes.yml.
  - flow: deviceCode
    standard: RFC 8628
    deviceAuthorizationUrl: https://aignostics-platform.eu.auth0.com/oauth/device/code
    tokenUrl: https://aignostics-platform.eu.auth0.com/oauth/token
    grant_type: urn:ietf:params:oauth:grant-type:device_code
    audience: https://aignostics-platform-samia
    scope: offline_access
    note: >-
      Documented in the getting-started guide and supported by the tenant
      (grant_types_supported includes the device-code URN) but NOT declared in the OpenAPI
      securityScheme. A client generated from the spec alone will only know about the
      authorization-code flow, even though device code is the flow the docs actually teach and the
      one the SDK uses for headless and CLI callers.
  sources:
  - openapi/aignostics-platform-api-openapi.json
  - https://aignostics.readthedocs.io/en/latest/get_started_api.html
credentials:
  issuance: manual
  detail: >-
    A user account is created by organization invitation; the client_id is obtained from
    support@aignostics.com. There is no client secret and no self-serve key generation. An
    organization must be registered by the business support team before any of this is possible.
  self_serve: false
  rotation: not documented
tokens:
  access_token:
    format: JWT
    audience: https://aignostics-platform-samia
    lifetime: not published
    validation: RS256 against the tenant JWKS
  refresh_token:
    issued_when: scope includes offline_access
    use: >-
      Renew the access token without a browser round trip - grant_type=refresh_token against
      https://aignostics-platform.eu.auth0.com/oauth/token.
  expiry_signal:
    status: 401
    body_observed: 'Jwt is missing'
    note: >-
      Observed live on 2026-09-14 at https://platform.aignostics.com/api/v1/applications - a
      plain-text body, not JSON. The docs say treat 401 as "renew and replay once".
delegated_access:
  mechanisms:
  - name: grant
    operation: create_grant_v1_access_grants_post
    subjects: [user, organization_admin, organization_user, share_token]
    relations_creatable: [viewer]
    note: Only viewer grants may be created through the API; anything else returns 422.
  - name: share token
    operation: create_share_token_v1_access_share_tokens_post
    parameter: share_token (query parameter on the run, item and artifact read operations)
    secret_handling: >-
      "The returned share_token value is shown only once and is never stored."
    expiry: caller-set expires_at at creation
    revocation: >-
      DELETE /v1/access/share-tokens/{share_token_id} "invalidates the credential regardless of any
      active grants".
    note: >-
      This is the one credential in the system a machine can mint for another machine - and it is
      well-shaped: single-display secret, caller-set expiry, independent revocation, and a
      least-privilege default of viewer. It is scoped to sharing results, not to submitting work.
secondary_credentials:
  warning: >-
    GET /v1/me returns the organization's Google Cloud Storage HMAC access key ID AND secret access
    key, a Logfire ingest token and a Sentry DSN inside the OrganizationReadResponse body. The
    identity endpoint is therefore also a credential-distribution endpoint: anything that logs,
    caches or forwards a /v1/me response is handling live storage credentials. See
    data-model/aignostics-data-model.yml.
  source: openapi/aignostics-platform-api-openapi.json (OrganizationReadResponse field descriptions)
gaps:
- id: device-flow-undeclared-in-spec
  detail: >-
    The flow the documentation teaches is absent from the machine-readable contract. Adding a
    deviceCode entry to the securityScheme flows would close the gap between the spec and the docs.
- id: empty-scopes
  detail: >-
    The oauth2 scheme declares zero scopes, so the contract expresses no authorization granularity at
    all - every token is, as far as a generated client can tell, all-or-nothing.
- id: staging-urls-in-the-vendored-spec
  detail: >-
    The OpenAPI copy vendored in the SDK repo at docs/source/_static/openapi_v1.json (info.version
    1.4.0) points its authorizationUrl and tokenUrl at
    https://aignostics-platform-STAGING.eu.auth0.com. The live document served at
    https://platform.aignostics.com/api/v1/openapi.json (1.8.0) correctly points at the production
    tenant. A developer generating a client from the repo copy - which the README links as the
    OpenAPI specification - gets a client that authenticates against staging.

Work with this as data

Every security artifact here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for security posture

4 MCP tools reach this
  • find_securityBrowse and filter every security artifact in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This security artifact
curl "https://apis.io/api/v1/security/aignostics-authentication"
All security posture
curl "https://apis.io/api/v1/security?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.