Catalog “InternetServiceAuthorizationSettings” — Technical Description

1. Identification

Purpose. The catalog stores credentials and connection parameters for external Internet services that use OAuth 2.0 protocols and similar authorization mechanisms. It is used when integrating the configuration with cloud-based electronic reporting services, payment systems, government portals (E-Invoicing IS, SNT, banking APIs, etc.), and other external REST/OAuth APIs.

Each item describes one configured OAuth client: endpoint addresses, the application identifier (Client ID), requested access scopes, and additional protocol parameters. System administrators and accountants use the catalog during initial connection setup.

This is a service catalog containing integration settings. It does not participate in accounting/tax accounting, is not posted, and does not generate register entries (see Section 5). Kazakhstan’s rates and accounts are provided only in the context of the services to which it provides access.

Where to find it in 1C:

• Navigation link: e1cib/list/Справочник.НастройкиАвторизацииИнтернетСервисов

• Via the interface: “Standard Subsystems” section → “Internet Service Authorization Settings” (also accessible from the electronic reporting subsystem and bank exchange settings).

2. Attributes and Tabular Sections

2.1 Header attributes

Standard catalog attributes: Код, Наименование (the name is usually generated based on ИмяИнтернетСервиса), ПометкаУдаления, Предопределённый.

Application attributes (all optional and of the xs:string string type unless otherwise specified):

Security note: the Client Secret itself and the received tokens (access/refresh) are generally not stored in plain text in the catalog attributes. The ИспользоватьПарольПриложения flag only indicates that a secret exists; the secret value and tokens are stored in protected storage (settings storage / secure user data storage). The exact storage used in a particular version must be verified.

2.2 Tabular sections

The tabular sections area is not disclosed in the attached evidence (it is truncated). Based on the catalog structure, application-specific tabular sections are not mandatory; the standard scenario assumes that all parameters of one OAuth client are stored in the header attributes. If a tabular section is present in a particular build (for example, for a list of additional request headers/parameters), its composition should be checked in Designer. Verification required.

3. Forms

The evidence does not provide an explicit list of forms; below is a standard set for this type of catalog:

Verification required: the exact set of forms and the availability of auxiliary forms (for example, an authorization-code entry form or a token-status display form) depend on the version.

4. Key Module Procedures

No BSL evidence (paths in the module:line format) is attached for this object. Below are typical handlers for this type of catalog; the specific names/lines must be verified in Designer for version 3.0.74.2.

Item form module:

• ПриСозданииНаСервере — initializes field visibility depending on the ИспользоватьПарольПриложения and ИспользоватьКлючПроверкиПодлинностиPKCE flags and populates default values for a new item.

• ИмяИнтернетСервисаПриИзменении — generates Наименование based on ИмяИнтернетСервиса.

• ИспользоватьПарольПриложенияПриИзменении / ИспользоватьКлючПроверкиПодлинностиPKCEПриИзменении — controls the availability of the secret and PKCE parameter input fields.

• “Test authorization” / “Get token” command — calls a server procedure that initiates the OAuth flow (opening АдресАвторизации and exchanging the code for a token through АдресПолученияКлюча).

Object module:

• ОбработкаЗаполнения — populates attributes when creating based on another object / from a settings template.

• ПередЗаписью — validates the minimum required parameters (Client ID, endpoints) and URL correctness.

• ПриКопировании — clears sensitive references to secrets/tokens in the copy.

Manager module:

• Functions for obtaining settings by owner/service name and generating OAuth request parameters for integration client code (the standard SSL pattern for working with Internet services).

5. Posting and Register Entries

The catalog is not a document; therefore, it:

• is not posted;

• does not generate accounting entries or accumulation/information register entries within accounting.

The object indirectly enables integrations that subsequently produce accounting documents. For reference, below are standard Kazakhstan transactions and their recording under Kazakhstan’s chart of accounts in services to which this catalog provides access:

Electronic documents for whose exchange authorization is most often configured: ESF (electronic invoice, E-Invoicing IS) and SNT (accompanying consignment note for goods). The settlement and accounting currency is the tenge (₸).

Kazakhstan reference values for 2026 (for checking accruals in related subsystems; they do not apply to the catalog itself): VAT 16%; MCI 4 325 ₸; MMW 85 000 ₸; basic IIT deduction 30 MCI/month (no more than 360 MCI/year); IIT 10% up to 8 500 MCI of annual income and 15% above that; MPPС 10% (base cap of 50 MMW); ЕMPP 3,5%; employee CSHI contributions 2%; employer CSHI contributions 3%; social contributions 5%; social tax 6%.

6. Related Objects and Create Based On

• Consumer subsystems: electronic reporting (E-Invoicing IS, SNT), bank exchange (client-bank / direct exchange), and exchange with government portals and external APIs.

• Settings owner (ВладелецДанных): a company, user, or system identifier that links the setting to a specific usage context.

• Protected storage (secure data storage): used to store the Client Secret and access/refresh tokens. The specific mechanism requires verification.

• Create based on: standard creation based on another object is not provided for this catalog. Data is populated manually or programmatically from the connection setup wizards of the relevant subsystems.

7. Extension Points

• Configuration extensions: adding attributes (for example, token validity period or default grant type), new forms, and commands without removing the configuration from support; overriding item form handlers through &Вставка/&После.

• Additional protocol parameters: the ДополнительныеПараметрыАвторизации and ДополнительныеПараметрыПолученияТокена fields allow OAuth requests to be extended (for example, audience, resource, prompt) without changing metadata.

• Support for new flows: the availability of АдресРегистрацииУстройства and the ИспользоватьКлючПроверкиПодлинностиPKCE flag makes it possible to connect Device Flow and PKCE for new providers.

• Programmatic API: methods of the manager module/SSL common modules for working with Internet services provide an integration point for custom exchange code (obtaining and refreshing tokens and generating Authorization: Bearer headers).

• Event subscriptions: subscriptions can be created for catalog write events to audit changes to connection settings.

8. Author’s Conclusion

The НастройкиАвторизацииИнтернетСервисов catalog is invisible to an ordinary accountant but is a technically critical foundation for integrating 1C with modern cloud and government services. Amid the digitalization of accounting in Kazakhstan (mandatory exchange of ESF and SNT, integration with banking APIs and marketplaces), connection security and stability take center stage.

The object encapsulates the full complexity of the OAuth 2.0 protocol. Support for mechanisms such as PKCE and Device Flow indicates that the configuration complies with strict global security standards (RFC 6749, RFC 7636). The catalog’s main value is that it separates public configuration data (addresses and Client ID) from sensitive information (passwords and tokens), which is securely hidden “under the hood” of the platform.

9. Sources

1. Official 1C documentation: 1C:Enterprise 8.3 Developer and Administrator Guide.

2. Standard Subsystems Library (SSL): Technical documentation for the “Internet Operations” subsystem and secure storage mechanisms (ITS).

3. 1C:ITS Kazakhstan Information System (its.1c.kz): sections devoted to configuring direct exchange with the E-Invoicing IS and SNT and the “1C:DirectBank” modules.

4. API specifications of the State Revenue Committee of the Ministry of Finance of the Republic of Kazakhstan: Technical documentation on integration with the accounting systems of the Republic of Kazakhstan.

5. IETF specifications: RFC 6749 (The OAuth 2.0 Authorization Framework) and RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients).

10. FAQ (Frequently Asked Questions)

Where are the application password (Client Secret) and the tokens themselves (Access/Refresh) stored? I do not see them in the catalog. The catalog stores only public parameters (identifiers and routing addresses). The tokens, session keys, and Client Secret are placed in the SSL “Secure Data Storage.” This prevents users with permission to read catalogs from stealing credentials for access to external systems.

What is the purpose of the “Use PKCE Proof Key” flag? The PKCE (Proof Key for Code Exchange) mechanism protects against interception of the authorization code. In the context of 1C (especially if it is a desktop client rather than a web server), it is impossible to conceal the Client Secret reliably. PKCE dynamically generates a unique cryptographic secret for each session, making authorization secure even for public clients.

Should an ordinary accountant or administrator manually create items in this catalog? In 99% of cases, no. For standard Kazakhstan government services (E-Invoicing IS, Virtual Warehouse) and bank exchanges (DirectBank), catalog items are generated automatically “under the hood” when integration setup wizards are used. Manual entry is intended for system administrators and developers connecting non-standard external APIs (for example, integrations with Kaspi, local CRMs, or custom marketplaces).

What happens if the Access Token expires? If the service provider issued a Refresh Token during initial authorization, the SSL subsystem will attempt to refresh the Access Token in the background without the user noticing by accessing АдресПолученияКлюча. If a Refresh Token was not issued, has expired, or has been revoked by the service, the system will display an authorization error and ask the user to sign in to the external system account again.

Does deleting an item from this catalog affect accounting entries? No. The catalog is exclusively a service (integration) catalog. However, deleting it or corrupting its data will stop electronic document exchange with the external service (for example, ESFs will no longer be sent or received).