How does software trust that you are you?
Source: Unsplash
By Sindre Seppola, Senior Solution Architect
Throughout my career, I’ve always found working with authentication systems to be intimidating and challenging due to the technical jargon and critical nature of such systems in modern software. It’s the kind of task you would leave to those who know what they are doing --until there’s no one better than you around to do it. This is the situation I found myself in mid-2021 at HUB Ocean: we needed to upgrade our authentication system integration to more accurately control who has access to what in our platform by using the OpenID Connect standard.
To wrap my head around the system, I noted a few key concepts that helped me reason about the system and generally made me more comfortable with authentication systems, whether it be Azure Active Directory, Auth0, or GoTrue. In particular, I’ve noticed how components of the system establish trust in what they receive, or in other terms: What does X expect to trust incoming requests? Perhaps this is a bit vague, so let’s consider the process by example.
Your physical mailbox
Imagine checking your mailbox one day and finding a letter saying:
“Transfer $100 to account 123.123.123”
Now obviously, this is a bit contrived, but let’s look at the steps we’d go through to determine the legitimacy of this request:
Ok, assuming:
You are the intended recipient of this letter, and
The sender is someone you would transfer 100 US dollars to if they requested it. Is this good enough?
Of course not. We know all too well in 2022 that anyone could have written it and dropped it in our mailbox in the hope of easy money. What we need to do before we actually perform the request is to acquire proof that it was requested by the person we think it was requested by.
We need to establish trust in the identity of the sender, so we give them a call to confirm ✅
Back to the digital world
The mailbox is an excellent example of how servers worldwide work because anyone can send requests to them. The main difference lies in that you cannot speak with a human to confirm their identity because it has to be done 10s of times per second! Therefore, to achieve this, we have to introduce a third party that we’re comfortable trusting-- in our case, that’s Azure Active Directory Business 2 Consumer (B2C), which is operated and developed by Microsoft.
B2C enables two important actions:
It enables users to create very fancy stamps 💌 that embed the sender, receiver, and the issuer of the stamp, packaged with a self-destruct mechanism so they can only be used for a short period.
The other thing B2C enables is a way for us to verify that the stamp and embedded information were actually issued by our B2C instance.
So on our server, we do precisely the same as we do in our mailbox example, but reversed:
This is in essence how authentication processes work across the internet. By keeping in mind how each component will verify the “stamp”, you’ll find it a lot easier to do your work. This is of course simplified and doesn’t consider authorization, or the process of deciding what the user should and shouldn’t be able to do. But the 1000m perspective should help you set some expectations for what has to happen on the ground.
It’s not magic
To prevent duplicate work the process of authenticating and authorizing requests are automated for developers of apps and services because
It’s very bad to get these things wrong
It is a very standardized process
It saves a lot of time
This may make it seem like magic, but somewhere something has to perform these 3 basic checks outlined before in order to identify the user securely.
How we use it
Having implemented OpenID Connect and OAuth 2.0 at HUB Ocean, we now have a single centralised place to manage users and access to our platform. We know that if we modify certain properties, B2C will enforce the changes across all systems within a short window of time.