Intermediate Backend Engineer, Authorization
GitLab is the intelligent orchestration platform for DevSecOps. GitLab enables organizations to increase developer productivity, improve operational efficiency, reduce security and compliance risk, and accelerate digital transformation. More than 50 million registered users and more than 50% of the Fortune 100* trust GitLab to ship better, more secure software faster.
The same principles built into our products are reflected in how our team works: we embrace AI as a core productivity multiplier, with all team members expected to incorporate AI into their daily workflows to drive efficiency, innovation, and impact. GitLab is where careers accelerate, innovation flourishes, and every voice is valued. Our high-performance culture is driven by our values and continuous knowledge exchange, enabling our team members to reach their full potential while collaborating with industry leaders to solve complex problems. Co-create the future with us as we build technology that transforms how the world develops software.
*Fortune 500® is a registered trademark of Fortune Media IP Limited, used under license. Claim based on GitLab data. Fortune 100 refers to the top 20% ranked companies in the 2025 Fortune 500 list, published in June 2025. Fortune and Fortune Media IP Limited are not affiliated with, and do not endorse products or services of GitLab.
An overview of this role
As a Software Engineer on GitLab's Authorization team, you'll help build and maintain the system that decides what every user, token, and automated agent can access on GitLab.com, Self-Managed, and Dedicated. You'll work alongside experienced engineers who guide the larger design decisions, delivering well-scoped changes and growing into ownership of larger parts of the system.
Today, that work is Ruby on Rails. Roughly 400 policy classes and a catalog of about 1,900 permissions sit behind every application programming interface (API) request. You'll work on fine-grained token permissions, custom roles, and the GraphQL and representational state transfer (REST) APIs that enforce them. A single request can trigger hundreds of permission checks, so correctness and performance both matter.
You'll also contribute to moving the permission model to a new authorization stack that pairs the Rails monolith with a Rust policy engine. The engine represents access relationships and evaluates permission rules, and can run within the monolith's process or be reached through remote procedure calls using gRPC. You don't need prior Rust experience: several engineers on the team learned it for this work, and we'll support you doing the same.
Some examples of our projects:
- Refactoring GitLab's policy layer so the same permission definitions can be evaluated by the monolith and the new authorization service
- Extending fine-grained token permissions to more resources, with guidance from senior engineers on the design
What you'll do
- Implement authorization changes in GitLab's Ruby on Rails monolith so permission checks allow intended access and deny unauthorized access.
- Deliver well-scoped workstreams from feature-flagged rollout through verifying that the old and new systems produce the same results, with review and guidance from senior engineers.
- Build and extend fine-grained permissions for tokens and roles so additional resources have permission coverage consistent with the established catalog.
- Extend and fix authorization enforcement so GraphQL and the REST API enforce the intended permissions consistently.
- Make incremental refactors to long-lived policy code without changing behavior for existing customers.
- Investigate and fix reliability, performance, and security issues so affected permission checks return the expected results without regressions.
- Work with the authentication, platform, and artificial intelligence (AI) teams to document interface contracts that keep permission checks consistent as authorization moves toward a shared service.
- Contribute to design documents, merge requests, and code reviews so proposed changes have a documented rationale and review feedback is addressed asynchronously.