Authlete — OAuth/OIDC SRE for Japanese banks
I operated and industrialised Authlete's deployments across three delivery models — on-prem, isolated SaaS, shared SaaS — for Japanese banking clients.
- GCP
- Kubernetes
- Helm
- Terraform
- GitLab-CI
- Java
- JUnit
- Ruby
- OAuth 2.0
- OpenID Connect
Context
Authlete sells OAuth 2.0 and OpenID Connect authentication to banks, primarily Japanese. Three delivery models coexist: on-premise (the client hosts), isolated SaaS (a dedicated instance per client) and shared SaaS. Each model has its own security, networking, and compliance constraints.
The challenge: industrialise these three models with a single template foundation, keep legacy versions supportable for as long as clients need them, and hit the OAuth / OIDC compliance bar on every release.
My role
SRE & DevOps. I owned the deployment templates, the multi-version CI/CD pipelines, and the SaaS operations on GCP.
What I built
- SaaS deployments on GCP operated daily
- Kubernetes templates with Helm + Terraform, designed to be cloud-agnostic so they could also serve on-prem clients without major code branching
- GitLab-CI pipelines capable of building and testing every legacy version of the service in parallel — because you can’t ask a banking client to migrate overnight
- Java JUnit test suite: unit + integration
- Ruby test suite: end-to-end + performance
- OAuth 2.0 / OpenID Connect compliance tests integrated into the pipeline, because an auth service that drifts from the spec stops being an auth service
- A massive cut in the time between “a dev pushes a fix” and “the fix runs in SaaS at the client”
The hard part: managing the matrix (delivery model × supported version × target cloud) without turning it into unmanageable configuration debt.
Results
Dev productivity sharply increased: changes flow through the automated test chain instead of waiting for manual QA cycles. The same template base serves SaaS and on-prem, which lowers the cognitive load on the SRE team.