redb.Identity Adds gRPC Transport for OpenID Server Alongside Existing HTTP Facade
redb.Identity has added a gRPC facade to its OpenID server, placing it alongside the existing HTTP transport on the same core routes. The server remains transport-agnostic: all authorization logic resides behind direct-vm://identity-* addresses, and both HTTP and gRPC now act as interchangeable facades over this kernel.
The new surface implements the protocol operations required by relying parties: Token at /identity.v1.Identity/Token (RFC 6749 §3.2), Introspect (RFC 7662), Revoke (RFC 7009), UserInfo (OIDC Core §5.3), Discovery, and Jwks (RFC 7517). A gRPC health check is also exposed via grpc.health.v1.Health/Check. Forty administrative operations across five services (Users, Applications, Groups, Scopes, Tokens) are available on a dedicated management port.
Requests accept the same key-value pairs defined by the RFCs plus a map<string, string> for extensions. Responses type the fields fixed by the specifications and place open sets such as claims into google.protobuf.Struct. OAuth errors are returned as gRPC status codes (UNAUTHENTICATED, PERMISSION_DENIED, RESOURCE_EXHAUSTED, INVALID_ARGUMENT) with the original error code and correlation identifier carried in trailers.
The same token issued through dynamic client registration over HTTP is accepted by the gRPC endpoint and yields identical authorization decisions. Scope evaluation occurs once inside the kernel at direct-vm://identity-authz-check, eliminating the risk of divergent policy between transports.
Browser flows (authorize, login, consent, MFA), DPoP proofs (RFC 9449), and user self-service remain exclusively on HTTP. The gRPC listener uses its own port because it requires HTTP/2 while the HTTP facade supports both HTTP/1.1 and HTTP/2.
Configuration is placed in the shared context.json under the identity.grpc section, allowing independent host, port, TLS, and compression settings. The EmitHttpCompatHeaders flag is enabled by default to preserve IP-based rate limiting and device metadata collection.
Related articles
StormWall Releases StormWall Appliance for On-Premises DDoS Protection
StormWall has introduced StormWall Appliance, a software solution that filters DDoS attacks inside the customer's own infrastructure rather than routing traffic to an external cloud. The product is aimed primarily at banks, hosting providers, internet service providers, and organizations with strict requirements for infrastructure availability and data control. It supports fully isolated networks through offline licensing with a hardware key and can operate independently or in a hybrid mode with StormWall's cloud platform. The appliance handles attacks at OSI layers L3 through L5, including volumetric floods, TCP stack attacks, reflection and amplification schemes, DNS attacks, and gaming protocols. It also processes TLS and QUIC traffic without decryption using DPDK and proprietary algorithms. Deployment takes as little as one day, with a 30-day free trial available after installation.
Developer Builds Custom Bouncer Tool to Automatically Block .env and SSH Probing on VPS
A system administrator running a small VPS with Caddy and static sites grew tired of constant password guessing attempts against SSH and repeated probes for files like .env, wp-admin, and config.php.bak. Instead of relying on Fail2ban, which required complex jail and filter configuration, the admin created a lightweight Rust-based tool named Bouncer. The program first crawls the site to build a list of legitimate paths, then monitors access logs and systemd journal entries for SSH invalid user attempts. IPs that generate multiple 404 responses for unknown paths or trigger SSH invalid user messages are added to an nftables set for automatic blocking. Special immediate bans are applied for direct hits on sensitive files such as /.env. The tool avoids double-counting SSH log lines, skips historical log replay on startup, and integrates directly with existing nftables rules without requiring additional runtime dependencies.
Russia Plans to Expand MAX Messenger with Unified Ticket Purchases Across All Transport Types
The Russian Ministry of Transport is developing new features for the MAX messenger to allow users to plan routes and purchase tickets for urban transport, trains, airplanes, and sea or river vessels within a single application. First Deputy Minister Konstantin Pashkov stated that the platform already supports verification of eligibility for discounted travel and handling of travel documents. Future plans include greater reliance on biometric identification, enabling passengers to complete bookings digitally and board using camera recognition without showing QR codes or physical documents. The initiative forms part of a gradual transition, with no immediate plans to phase out existing payment methods. New regulations effective from September 1 permit confirmation of social benefits through MAX and the use of biometric services where carriers have the required equipment. No specific timeline for full implementation of integrated ticketing has been provided.
5G Icon Appears on Select iPhones for Russian Users as Operators Expand Coverage
Some iPhone owners in Russia have observed the 5G indicator replacing LTE in the status bar, marking the first signs of fifth-generation network access on Apple devices. The change has been confirmed by a RIA Novosti correspondent but remains limited to a portion of users, with no official details released on supported models, carriers, or regions. Russian operators from the Big Four launched 5G services in 16 cities one week earlier, granting potential access to roughly 10 million subscribers. The initial rollout operates primarily on previously allocated LTE spectrum bands, delivering an estimated 20-25% increase in network throughput. Unlike Android devices, where the Ministry of Digital Development planned to enable compatible hardware directly, iPhone activation requires Apple to authorize specific operator frequencies and network configurations. Observers note that the presence of the 5G icon does not yet guarantee widespread deployment or significant speed gains, as performance depends on coverage, spectrum, device model, and network load.