Why “auth”?

If you ask me what I focus on in tech, I’ll tend to say “auth”, a subset of identity, which is itself a subset of information security. I define “auth” as the process, technology, and user experience of “getting in” and accessing resources. This includes sign in / authentication, authorization / consent, ongoing session management (how long you are signed in and when you have to re-auth), and account recovery. The more standard industry term “identity” includes many things I won’t do justice here (identity management, governance, entitlements management, regulatory compliance, auditing, privileged access management, etc) because they are boring.

Introduction

Introductions are so annoying. Why isn’t the prologue just chapter 1? What is the author trying to prove? The length of their backstory? The depth or complexity of their work? I’m not sure. It seems so self-important.

Picture it: Redmond, Washington, 2010. A young identity professional is dealing with the aftermath of the great recession…

Just kidding.

It was somewhere between 2006 and 2008, I think (please don’t try to pin me down on dates – the last 20 years are kind of a hazy blur), when I learned that Microsoft planned to create a version of Active Directory in the sky … er … cloud. This cloud was also where Office 365 was being conceived.

A couple of years later, I ended up in the business of connecting company networks to this cloud.

I remember thinking that this directory-in-the-sky was not necessary. The existing on premises identity systems could easily authenticate users and send claims to Office 365. No need to create redundant shadow accounts in the cloud.

I was technically correct. Also, I should never, ever, be put in charge of the business side of a software behemoth.

Like, not ever.