DEV Community

oleg makhlov
oleg makhlov

Posted on

OAuth Is Not the Hard Part. Identity Platform Automation Is.

When I first started working on an Identity Platform, I assumed the hardest part would be implementing OAuth 2.0 and OpenID Connect.

I was wrong.

Today, there are excellent solutions such as OpenIddict, Keycloak, Duende IdentityServer, Auth0, and many others. They already solve the difficult protocol problems: issuing tokens, validating signatures, supporting PKCE, refresh tokens, and implementing OAuth/OIDC flows.

The real challenges appear after OAuth is already working.

A new API needs to be registered as a resource.

A new application needs an OAuth client.

A SPA needs redirect URIs and CORS configuration.

A service needs permissions.

A new tenant needs isolated configuration.

An environment needs cryptographic keys.

None of these tasks are particularly complicated.

But together they create a significant operational burden.

This made me think about a simple question:

Why do Identity Platforms still require so much manual configuration?

Software infrastructure has already moved toward automation.

We have Infrastructure as Code.

Cloud platforms provision resources automatically.

CI/CD pipelines deploy applications automatically.

Almost every part of modern software delivery has automation as a default approach.

However, Identity Platforms often still require administrators to open a management console and manually create clients, scopes, permissions, and security configuration.

What if Identity configuration could be automated in the same way?

Imagine creating a new API and having the platform automatically:

register the resource;
generate permissions;
generate OAuth scopes;
make them available to client applications.

Imagine creating a new SPA application and having the platform automatically:

create the OAuth client;
generate the Client ID;
configure redirect URIs;
configure CORS;
enable PKCE;
assign permissions.

Imagine creating a new tenant and automatically provisioning:

an isolated OAuth environment;
resources;
client applications;
cryptographic keys;
security configuration.

This does not require changing OAuth.

OAuth 2.0 and OpenID Connect already solve authentication and authorization very well.

The next step is not a new protocol.

The next step is automating everything around these protocols.

Resource registration, client provisioning, scope and permission management, CORS configuration, tenant provisioning, and cryptographic key management are predictable and repetitive tasks.

And predictable, repetitive tasks are usually good candidates for automation.

This idea became the foundation of SolNeat Identity.

The goal was not to create another OAuth implementation.

The goal was to reduce the operational work required to run an Identity Platform by automating as much of its lifecycle as possible.

Demo

I recorded a short demonstration showing some of the automation concepts:

creating client applications;
generating OAuth configuration;
managing resources and permissions;
working with tenant-specific environments.

You can watch the demo here:
https://www.youtube.com/watch?v=QvqTafiDIgs&t=2s

Project

SolNeat Identity is an Identity Platform focused on automating OAuth/OIDC configuration and reducing repetitive operational tasks around identity management.

More information:
https://id.solneat.com/

I believe Identity Platforms will continue moving in the same direction as infrastructure and application delivery.

A future where resources, clients, scopes, security policies, and cryptographic keys are automatically provisioned may become as normal as Infrastructure as Code and CI/CD are today.

And when that happens, manually configuring Identity Platforms may feel as outdated as manually deploying servers.

Top comments (0)