FusionAuth | Senior Java Engineer, Technical Support Engineer, Senior UX Designer, Account Executive | Varies between REMOTE (in USA, also in Europe but only for the sales positions) and ONSITE in Denver, CO, USA, details in each job desc | Salary ranges listed on job req, but for the Senior Java Engineer it is 140k-180k
At FusionAuth, our mission is to make authentication and authorization simple and secure for every developer building web and mobile applications. We want devs to stop worrying about auth and focus on building something awesome. We also recently acquired a fine-grained authorization company ( https://fusionauth.io/blog/fusionauth-acquires-permify ) and are going to be building in that area as well.
There are a lot of companies in the auth space, but we feel like we have something special:
* a unique deployment model (self-host on-prem or in your cloud or run in our cloud)
* A well designed API first approach; one customer compared our APIs to petrichor
* a mature product (the code base is nine+ years old and we've found and fixed a lot of the sharp edges around core login use cases; but don't worry, there are plenty more features to add)
* our CTO is the founder and still writes code
* a full featured free-as-in-beer version which makes the sales cycle easier; prospects often come in having prototyped an integration already
Our core software is commercial. We open source much of our supporting infrastructure. Technologies and standards that you will work with: modern Java, PostgreSQL, Docker, Kubernetes, MySQL, OAuth, SAML, OIDC.
Learn more, including about benefits and salaries, and apply here: https://fusionauth.io/careers/ ( Click/tap the 'View open positions' orange button. )
> Wouldn't the client credentials app be a good fit for this? Or do you need user consent/scopes?
If OAuth is already part of the product, switching flows only for preview environments isn’t really an option. It introduces a second auth path that doesn’t exist in production, which adds complexity and creates a risk of auth bugs that only appear later. In practice, teams want previews to exercise the same OAuth flow as prod, not a simplified one.
> For redirect URLs, some identity providers let you configure them via an API key.
That still means introducing provisioning and deprovisioning steps for every ephemeral environment. For example, platforms like Vercel give you PR-based preview URLs out of the box, but it’s not at all obvious how to automatically add and remove redirect URLs in the IdP for each of those. Auth becomes a special case that needs extra orchestration, while everything else is disposable.
> Which resources are protected by OAuth that you want these AI agents to interact with?
The issue isn’t agents accessing OAuth-protected resources directly. It’s agents building and testing applications that themselves rely on OAuth. The pain point is getting fully functional ephemeral environments when OAuth assumes static, pre-registered redirect URLs.
> The most confusing part of terraform for me is that terraform's view of the infrastructure is a singleton config file that is often stored in that very infrastructure.
That article is way overkill. One should just manually create the backend storage (S3 bucket or whatever you use). No reason to faff about with the steps in the article.
The reason to not create the bucket are because you want to ensure that you don’t have any click ops resources that you can’t track. If you manually create anything, that means it’s not in code and therefore the rest of the team doesn’t know where it lives, who created it, or when.
When you have a hammer… as the expression goes. It’s crazy how many times that even knowing this, I have to catch myself and step back. IaC is a contextually different way of thinking and it’s easy to get lost.
Interesting. It'd be stronger if you didn't make claims that just aren't true. For example:
> Three months later when someone asks "why did we switch from X to Y?", I have the full rationale documented. Not just the decision, but the alternatives considered and why we rejected them.
But you just started 3 weeks ago. So what you really meant is:
> Three months later when someone asks "why did we switch from X to Y?", I will have the full rationale documented. Not just the decision, but the alternatives considered and why we rejected them.
But all in all inspiring. I am going to take a swing at my own executive assistant using opencode (with Claude under the hood).
At FusionAuth, our mission is to make authentication and authorization simple and secure for every developer building web and mobile applications. We want devs to stop worrying about auth and focus on building something awesome. We also recently acquired a fine-grained authorization company ( https://fusionauth.io/blog/fusionauth-acquires-permify ) and are going to be building in that area as well.
There are a lot of companies in the auth space, but we feel like we have something special:
* a unique deployment model (self-host on-prem or in your cloud or run in our cloud)
* A well designed API first approach; one customer compared our APIs to petrichor
* a mature product (the code base is nine+ years old and we've found and fixed a lot of the sharp edges around core login use cases; but don't worry, there are plenty more features to add)
* our CTO is the founder and still writes code
* a full featured free-as-in-beer version which makes the sales cycle easier; prospects often come in having prototyped an integration already
Our core software is commercial. We open source much of our supporting infrastructure. Technologies and standards that you will work with: modern Java, PostgreSQL, Docker, Kubernetes, MySQL, OAuth, SAML, OIDC.
Learn more, including about benefits and salaries, and apply here: https://fusionauth.io/careers/ ( Click/tap the 'View open positions' orange button. )
reply