generated: '2026-09-02' method: probed source: >- https://auth.solvewithvia.com/auth/realms/qt/.well-known/openid-configuration (HTTP 200) and https://auth.solvewithvia.com/auth/realms/ztf_demo/.well-known/openid-configuration (HTTP 200), fetched anonymously 2026-09-02; corroborated by the VIA ZTF integration guide at https://documentation.ztf.solvewithvia.com/integration/ and the tutorial sources at https://github.com/viascience/ztf-tutorial. name: VIA (Via Science, Inc.) — authentication profile docs: https://documentation.ztf.solvewithvia.com/integration/ summary: >- VIA does not publish an API-key surface. Every VIA product surface — the Quantum Transfer (QT) application, the ZTF demo, and any application a customer integrates with VIA Zero Trust Fabric — authenticates through a VIA-operated Keycloak identity server at auth.solvewithvia.com using OpenID Connect Authorization Code + PKCE. The discovery document is served anonymously per realm, so the full endpoint set, signing algorithms, grant types and client-authentication methods are machine-readable without credentials. ZTF layers decentralized identity on top: passwordless login backed by W3C Verifiable Credentials held in the VIA Wallet, with wallet-signature step-up for sensitive actions. schemes: - name: openIdConnect type: openIdConnect in: header scheme: bearer format: JWT openIdConnectUrl: https://auth.solvewithvia.com/auth/realms/qt/.well-known/openid-configuration description: >- OpenID Connect on the VIA Keycloak realm `qt` (Quantum Transfer). Browser clients use Authorization Code with PKCE (S256); the resulting access token is presented as an HTTP Authorization: Bearer JWT. source: well-known/via-science-qt-openid-configuration.json - name: openIdConnect-ztf-demo type: openIdConnect in: header scheme: bearer format: JWT openIdConnectUrl: https://auth.solvewithvia.com/auth/realms/ztf_demo/.well-known/openid-configuration description: >- OpenID Connect on the VIA Keycloak realm `ztf_demo`, the realm backing the public ZTF demo at https://demo.ztf.solvewithvia.com/ and the published tutorials. source: well-known/via-science-ztf-demo-openid-configuration.json - name: mutualTLS type: mutualTLS description: >- The discovery document advertises `tls_client_auth` as a client-authentication method and `tls_client_certificate_bound_access_tokens: true` (RFC 8705 certificate-bound access tokens). Available, not required. source: well-known/via-science-qt-openid-configuration.json - name: wallet-signature-step-up type: signature in: body description: >- ZTF step-up authentication. Sensitive operations require an additional digital signature produced by the user's VIA Wallet over WalletConnect v2, verified server-side before the action is allowed. Documented in tutorial-2-step-up-auth and tutorial-2-owasp-prompt-injection, whose backend ships both a jwtAuth and a signatureAuth middleware. source: https://github.com/viascience/ztf-tutorial/tree/master/tutorial-2-step-up-auth note: >- This is VIA's stated defence against an AI agent acting on a user's behalf without explicit consent — the bearer token alone is not sufficient for a sensitive call. endpoints: qt: issuer: https://auth.solvewithvia.com/auth/realms/qt authorization: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/auth token: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/token userinfo: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/userinfo jwks: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/certs end_session: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/logout introspection: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/token/introspect revocation: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/revoke registration: https://auth.solvewithvia.com/auth/realms/qt/clients-registrations/openid-connect device_authorization: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/auth/device pushed_authorization_request: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/ext/par/request backchannel_authentication: https://auth.solvewithvia.com/auth/realms/qt/protocol/openid-connect/ext/ciba/auth ztf_demo: issuer: https://auth.solvewithvia.com/auth/realms/ztf_demo authorization: https://auth.solvewithvia.com/auth/realms/ztf_demo/protocol/openid-connect/auth token: https://auth.solvewithvia.com/auth/realms/ztf_demo/protocol/openid-connect/token userinfo: https://auth.solvewithvia.com/auth/realms/ztf_demo/protocol/openid-connect/userinfo jwks: https://auth.solvewithvia.com/auth/realms/ztf_demo/protocol/openid-connect/certs end_session: https://auth.solvewithvia.com/auth/realms/ztf_demo/protocol/openid-connect/logout uma2_resource_registration: https://auth.solvewithvia.com/auth/realms/ztf_demo/authz/protection/resource_set uma2_permission: https://auth.solvewithvia.com/auth/realms/ztf_demo/authz/protection/permission uma2_policy: https://auth.solvewithvia.com/auth/realms/ztf_demo/authz/protection/uma-policy grant_types_supported: - authorization_code - client_credentials - implicit - password - refresh_token - urn:ietf:params:oauth:grant-type:device_code - urn:ietf:params:oauth:grant-type:jwt-bearer - urn:ietf:params:oauth:grant-type:token-exchange - urn:ietf:params:oauth:grant-type:uma-ticket - urn:openid:params:grant-type:ciba client_authentication_methods: - private_key_jwt - client_secret_basic - client_secret_post - tls_client_auth - client_secret_jwt token_format: JWT id_token_signing_algs: - RS256 - RS384 - RS512 - PS256 - PS384 - PS512 - ES256 - ES384 - ES512 - EdDSA - HS256 - HS384 - HS512 features: pkce: true pkce_methods: [plain, S256] dpop: true pushed_authorization_requests: true par_required: false dynamic_client_registration: true device_authorization_grant: true ciba: true token_exchange: true uma2: true mtls_bound_access_tokens: true front_channel_logout: true back_channel_logout: true request_object: true claims_parameter: true claims_supported: [iss, sub, aud, exp, iat, auth_time, name, given_name, family_name, preferred_username, email, acr, azp, nonce] acr_values_supported: ['0', '1'] api_keys: supported: false note: >- No API-key issuance is documented on any public VIA surface. Machine-to-machine access would use the OIDC `client_credentials` grant advertised by the realms above; client provisioning is not self-serve — it goes through the "Get a demo" form. gaps: - >- No OpenAPI or other machine-readable REST contract is published for any VIA product, so the securitySchemes above are recorded from the OIDC discovery documents and the integration guide rather than derived from a spec. - >- No public self-serve signup: realm clients are provisioned by VIA. The auth surface is fully readable anonymously; the resource APIs behind it are not.