User Functionality Part 2: Making Authentication a Framework Responsibility

Once I had decided that the website should have user accounts, I had to answer a fairly important question.

Where should authentication live?

The obvious answer, if I was thinking about the individual applications, would have been to put it in each application. After all, an application needs to know whether someone is logged in.

But that immediately brought me back to the problem that had started the whole framework project in the first place.

Duplication.

If Publications had its own authentication system, and Marketplace had another, and another application had another, I would once again have several versions of essentially the same functionality.

That wasn't what I wanted.

If a user account belonged to the website rather than to an individual application, then authentication needed to belong to the platform as well.

That was an important distinction.

The applications shouldn't each have to work out how to authenticate a user. They should simply be able to ask the framework whether there is an authenticated user and, where appropriate, obtain the information they need about that user.

In other words, authentication became a framework service.

This was another step in changing how I thought about the project.

Originally, I had a collection of applications with some shared code. Now I was beginning to have a platform that provided services to those applications.

The distinction between the two became increasingly clear.

An application should contain the functionality that makes that application unique.

The framework should contain the infrastructure that applications have in common.

Authentication was one of the clearest examples of this principle.

It also meant that sessions became a framework concern. If a user was logged in, that state needed to be handled consistently regardless of which application they were using.

This sounds straightforward now, but it represented a significant change from the way the individual applications had originally been built.

I was no longer asking, "How do I make this application work?"

I was increasingly asking, "What should the platform provide so that every application can work in the same way?"

That question led to another important part of the architecture: the account area itself.

If the framework knew who the user was, it made sense for the framework to provide a common place where that user could see the functionality available to them.

That eventually led to the idea of framework-owned capabilities.

Rather than each application creating its own completely separate account experience, the account area could provide a consistent structure, with individual applications contributing the capabilities relevant to their functionality.

This approach also gave me a way of separating identity from application functionality.

The framework knows who you are.

The application knows what you can do within that application.

Those are related, but they aren't the same thing.

That distinction became increasingly useful as the project grew.

It meant that adding another application didn't require inventing another user system. The new application could use the identity and authentication infrastructure that already existed.

It also meant that improvements to authentication could be made centrally rather than repeatedly across several applications.

And that brought me back to the principle that had started the framework in the first place.

Make the change once.

If authentication is a framework service, then an improvement to authentication is a framework improvement.

Every application using the framework benefits from it.

What had begun as a simple decision to add user accounts was therefore becoming another example of the framework's purpose.

I wasn't just adding functionality.

I was deciding where that functionality belonged.

And that distinction—between what belongs to an application and what belongs to the platform—would become one of the most important architectural questions in the entire project.