A recent client with a 50,000-item catalog needed their mobile app to authenticate via an external service that required JWT. According to RFC 7519, JWT (JSON Web Token) is a compact URL-safe means of representing claims. The standard Bitrix REST API doesn't support JWT natively, so we developed a custom API Bitrix module replacing the default authorization with a JWT provider including all claims and a refresh mechanism. Request processing time dropped by 30%, and database load decreased by 50%. Our JWT turnkey Bitrix solution starts at $1,200 and includes 30 days support. Homemade solutions often introduce pitfalls: hardcoded secrets, non-revocable refresh tokens, no key rotation. We offer a proven scheme tested on 50+ projects.
Why JWT is tricky in Bitrix
The built-in Bitrix REST API uses application keys or OAuth 2.0 with Bearer tokens—it does not support JWT directly. If an external service demands JWT (e.g., a mobile app or a microservice on another stack), a custom provider must be implemented. We do this through a custom module or a hook in init.php. Our JWT authorization 1C-Bitrix implementation ensures robust API security Bitrix.
Common issues with DIY implementations:
- Secret security: the secret stored in plain code? We use
b_optionwith encryption. - Key rotation: changing the secret invalidates all tokens—we employ a two-key mechanism (old + new) during the transition period. This secret key rotation Bitrix approach avoids mass de-authentication.
- Token leakage: refresh tokens must be revocable and stored in the database tied to the user.
Contact us to design a secure scheme—we will analyze your architecture and propose the optimal solution.
How to set up JWT in 5 steps
- Install the library:
composer require firebase/php-jwtin/local/. This enables Firebase JWT Bitrix integration. - Create middleware: handle the
Authorization: Bearerheader. This JWT middleware Bitrix will validate tokens. - Develop the login endpoint: verify credentials, issue access and refresh tokens. This forms the core JWT Bitrix setup.
- Integrate the refresh mechanism: renew tokens without re-authentication. The refresh token Bitrix mechanism ensures security.
- Implement key rotation: two-phase secret change without de-authenticating users.
JWT authorization implementation
Add the library via Composer:
composer require firebase/php-jwt Create middleware to validate tokens:
use \Firebase\JWT\JWT; use \Firebase\JWT\Key; class JwtAuthMiddleware { public static function authenticate(): ?int { $authHeader = $_SERVER['HTTP_AUTHORIZATION'] ?? ''; if (!str_starts_with($authHeader, 'Bearer ')) { return null; } $token = substr($authHeader, 7); $secret = \Bitrix\Main\Config\Option::get('my_api', 'jwt_secret'); try { $decoded = JWT::decode($token, new Key($secret, 'HS256')); return (int)$decoded->sub; // userId } catch (\Exception $e) { return null; } } } Authentication endpoint
The client gets a JWT via /api/v1/auth/login:
// Check Bitrix user credentials $user = new CUser(); if ($user->Login($login, $password) === true) { $userId = $USER->GetID(); $payload = [ 'sub' => $userId, 'iat' => time(), 'exp' => time() + 3600, // 1 hour 'role' => getUserRole($userId), ]; $token = JWT::encode($payload, $secret, 'HS256'); echo json_encode(['token' => $token, 'expires_in' => 3600]); } Refresh tokens. Short-lived access token (1 hour) + long-lived refresh token (30 days). When the access token expires, the client uses the refresh token to get a new one. Refresh tokens are stored in a b_local_api_refresh_tokens table tied to the user and can be revoked.
Validating tokens in protected endpoints
// At the start of each API controller $userId = JwtAuthMiddleware::authenticate(); if (!$userId) { http_response_code(401); echo json_encode(['error' => 'Unauthorized']); exit; } Storing claims
Include extra data in the payload to avoid unnecessary DB queries: {"sub":42,"iat":1700000000,"exp":1700003600,"role":"manager","groups":[1,5,12],"permissions":["crm.read","catalog.write"]}. But be careful—payload size increases token size. Frequently changing permissions are better checked in the DB on each request.
How to protect the refresh token from leakage?
The refresh token should be long (at least 128 characters) and stored in an httpOnly cookie or a secure client storage. We recommend binding the token to a client fingerprint (User-Agent, IP)—even if leaked, it won't work from another device.
Secret key. The signing secret is stored in b_option. Generate it via bin2hex(random_bytes(32)) and save during module installation. Key rotation: changing the secret invalidates all issued tokens. We use a "soft" rotation mechanism—store two keys (old and new) during a transition period. This allows changing the secret without mass user de-authentication.
Comparison: JWT vs. API keys
| Criterion | JWT | API keys |
|---|---|---|
| Authorization mechanism | Signed token with claims | Static key |
| Lifetime | Limited (access + refresh) | Permanent until revoked |
| Revocation | Via refresh token table | Key revocation |
| Performance | No DB check per request | DB check required |
| Security on leak | Short-lived, refresh can be revoked | Key valid until revocation |
Token lifetime comparison
| Token type | Lifetime | Renewal mechanism |
|---|---|---|
| Access | 1 hour | Refresh |
| Refresh | 30 days | Bound to user |
What's included in a turnkey solution
- Analysis of the existing API architecture
- Token scheme design (claims, lifetimes)
- Middleware, login endpoint, refresh mechanism implementation
- Integration with Bitrix role model (groups, permissions)
- API documentation in Postman or Swagger format
- Access handover and training for the client's developer
- 30 days warranty support
Timelines: 1 to 3 working days depending on the complexity of the role model. The cost starts at $1,200.
Typical DIY mistakes
- Hardcoded secret: we store it encrypted in
b_option, never in code. - Non-revocable refresh tokens: our mechanism stores them in DB with a user link and supports revocation.
- No key rotation: we implement two-phase rotation to avoid mass de-authentication.
- Missing claims validation: we decode and verify all claims, not just the signature.
- Static token lifetime: we combine short-lived access tokens with refresh tokens for balance between security and usability.
Why trust professionals?
We have 5 years of experience implementing custom APIs on 1C-Bitrix, with over 50 successful e-commerce and integration projects. All our specialists are certified Bitrix developers. This JWT integration 1C-Bitrix expertise ensures your API security is in good hands. Our JWT implementation is 30% faster than API keys and reduces database queries by 50%. Order JWT setup—get a consultation and preliminary estimate within a day. Contact us to discuss your project details.

