Ep. #9, Auth*orization with Jeff Taylor of Okta

Kim Harrison: Jeff, why don't you tell us more about yourself and your role with Okta?

Jeff Taylor: Yeah, I'm Jeff Taylor.

I'm a senior product manager working in our developer experience arm of Okta, and mainly, I'm responsible for the SDKs and tools and other dev tools.

So we're responsible for getting our customers up in their customized environments.

So if they want to customize the auth experience, they're using our SDKs to integrate with Okta and they do all the things that their customers need.

On the dev tool side, we're just looking at making it easier for our customers to basically own and operate their entire authentication process.

So we're doing things like helping with Terraform.

We're looking to get into other markets of CI and CD, which are really exciting for us, and to help bridge the gap between app developers and development operations to sort of pull in the whole app development life cycle.

So that's some of the big rocks that I'm working on.

Heidi Waterhouse: Excellent. So this podcast is called Unintended Consequences.

And what we're here to talk about is the things that we didn't expect when our plan went well or the things that we didn't expect to go wrong.

And I think it's really interesting to listen to you talk about the APIs and think about what it is in APIs which we think of as being relatively slow moving and stable.

What is the hard part of getting people up and running?

Jeff: It's a little bit about merging the two domains.

So the way I look at this is you've got two pieces of the puzzle. I'm an app developer.

Coming in, I've got my business objectives for my application and I want to do something like authentication.

I've got to figure out, "Well, what does this actually mean to integrate with authentication and how am I going to seamlessly integrate that so I can understand the things that I need about authentication, but I don't disrupt any of my business needs?"

So it's about finding this balance, right?

On how I can get my job done without having to become an expert in two worlds, one that's only going to be a temporary thing because I've just got to get this in for the short term, but I've really got all of these other objectives that I've got to achieve on the other side.

So I think that's really-- One of the difficult parts is how do you get enough information to go forth and do as opposed to just being mired and trying to understand everything about a given subject.

I think finding that, striking that right balance is really the hardest part.

And then it's that initial inertia where like, "Okay, I feel like I've got my wings under me. I'm ready to fly and leave the nest and actually integrate with this thing."

Heidi: I really like that you brought it back to business value.

I think this is a constant sort of tension between security organizations as a whole and companies.

It's like the most secure thing would be not to talk to anybody on the internet.

And that's not really a great option for most of us.

So how can security be making business value work better?

And I think that's one of the great things about what you all are doing is like this, once it's working, this seamless you don't have to log in all the time using different passwords thing.

It just magically works for you. When it goes wrong, what does it look like?

Jeff: I guess the first thing when you're talking about authentication and security, the first emotion that I usually have when I'm reading these articles is empathy for the embarrassment that another company may feel because something has happened and the trust that you worked so hard to build with your users takes a hit.

In my background, I've been very much a humanist.

I'm very much interested in the human condition.

And part of what pulls me into these articles is the emotions that are going on across all of the boards that are affected, like the consumers that have to figure out what to do with their accounts all the way down to the CISO that has to answer for the questions of how this could happen, all the way down to the operators or the developers that may have left a hole in. It ripples through and creates this kind of chasm.

And so what it looks like is--

I think that if you take a macro look at this, it opens up a lot of inspection on a lot of different areas from the software to the leadership, to the processes, and in some cases, to some of the other practices that are going on in an organization.

So it's like flinging a door open to a closet that may or may not be organized and having a lot of things sort of fall out and you're rushed to having to clean that up, and also get on that road to reestablishing trust with your end users.

So I just think it's one of those--

It's a, I want to say a Pandora's box, but there's just a lot that happens once this goes wrong, that you have to run damage control and there's little fires here and there that you've got to answer for to really put that out.

Heidi: That's awesome.

I think that I love that analogy of a guest has come over and instead of opening the coat closet, they opened the closet that you shoved everything into right before they came over.

Maybe this is just my post-pandemic planning.

I'm like, "Oh, a friend's coming into town. Let's meet you at a museum somewhere else."

Jeff: Yeah.

Heidi: But as businesses, we don't get to do that.

So when I think about what you're doing, I think about all the things that have come before and all the other times we've tried to homogenize and federate our identities and the different ways that they've failed.

What do you think sort of the most interesting failure of identity management has been?

Jeff: Oh, yeah, this was one of my favorite ones.

It's like trying to make more secure passwords. That's been my favorite.

Actually, I lived through this too at my last job.

So I was running an authentication, identity and access management for our consumers.

And we have this constant tug and pull of like, "Should the password be eight or 12 characters?"

And there's a lot of math. I got into the entropy between the digits and how it gets to points where it can defeat the rainbow table and all sorts of fun things.

And ultimately, the consumers that respond, they're like, "I hate this. If you just make this easier, I could sign up for your application."

But we're like, "No. 12 characters. Got to have a mix of symbols and numbers. Can't have common words in it."

So the things that you would naturally gravitate toward remembering your password, you can't use.

And I think the other part of this is the solution that kind of doubles down on this, which is a--

It's a better solution, but like having a vault, which is saying, "Instead of writing your passwords down on a post-it that you can attach to your desk, write it down in your secure vault, which, of course, you need a stronger password to secure."

So it's kind of this metaconcept of using the thing that doesn't have high usability to secure the low usability thing.

It's just this thing that keeps lapping over itself.

And I find it amusing that we've gone this far with it.

And you look at even some of the more secure banking applications.

They go a little bit crazy with it. But what's interesting is that now, users have just started to push back with a collective voice saying, "There's just got to be a better way in."

Luckily, we've now crossed and meshed along where there are a lot more opportunities to kind of remove the password or put less importance on the password for our consumers.

Kim: I have a couple of questions.

I want to ask about these other methods, but first, what is the rainbow table?

Jeff: Oh, so this rainbow table is like a dictionary of commonly used passwords that you can just brute force and run through.

It's what some things that attackers will use to guess passwords.

So you might see these in some cases where you have low entropy in your passwords. You'll--

Heidi: Which means there are only six digits and you don't have to have special characters.

So if you have just six letters, that's a low entropy password.

Jeff: Exactly.

So if you have it with one symbol and five characters between A and Z, capitalized, whatnot, I can just build a table of all the possible responses and just run through them if I've got the time and there's no security on the other end, nothing like a lockout or something.

And the worst is, if there's a time delay, just wait and try it again.

But some people get sophisticated enough to just do proper guessing on them so they can guess a user's password.

But that's one of the things that I think is really hard about that.

I think its recommended length is something like 16 characters.

It's really hard to do that. There's just so many combinations.

And if you look at a lot of password vaults, that's kind of what they'll recommend.

They'll generate them for you and so you can secure your access to sites.

Heidi: My streaming for watching the Tour de France made me do 10 characters with a special character and also rules on where the capitals fell.

And I'm just like, "Really? I'm just here to watch the Tour de France. Come on."

Jeff: Exactly. And that's in the essence of how absurd it gets with the password policies.

The time it takes for you to create your password depreciates the value on the service that you're getting.

So I think what's interesting is that then links to the business case where users just don't want to sign up for your service.

Even if they find it valuable, the friction that it causes for them to sign up and get an account so they can use that service, it kind of flips the script and so they just won't sign up.

And it's really interesting to see how that could affect your bottom line.

Kim: Can I admit something terrible?

And I hope nobody tries to figure out which account I'm talking about, but there is one account that I had to use to pay a bill on the regular and I kept forgetting the password so I just got in the habit of resetting my password every time I had to log in and pay the bill on a quarterly basis.

Heidi: That's better than reusing a password.

Jeff: Actually, so a long time ago in a past life, I actually had a person that I worked with, that was their standard operating procedure.

They would just randomly generate a password every time that they had to use a service.

And if it's strong enough or you just have to remember it that one time and you just go and reset.

As long as there's no requirements like you can only do one password change in a week, most of these are set to 24 hours.

But yeah, if you're not using something frequently, you know that it's secure, like you're paying a bill every month or every quarter or something like that, then yeah, that's totally viable because now you're not creating something that's too easy to guess.

You're creating something that's super random.

You have an opportunity to make that longer and more complicated because you don't care about remembering it.

So it's not a terrible practice.

Kim: I feel a little bit better knowing that.

Jeff: Well, because that's-- In my journeys through security, I think that's one factor that-- People worry about complexity.

There's this dangling factor of time, right?

If you look at key rotations and stuff, that's why this comes into play.

I want to keep the attacker guessing so that the credential will constantly change so that you've got this other variable that they have to account for, not just the complexity.

So I think what you're doing, if you're doing that manually, you're saying, "You've got the short time window in which you can guess it."

But now it's combined with these other factors of the complexity and the strength and how I'm actually constructing the password so it makes it a lot more difficult to guess if you're applying all of those at a high level.

Heidi: So I want to sort of loop back to a thing where we were talking about vaults, like the intended consequence is that everyone will set a unique, strong password for every service they use.

That is sort of the stated goal. But the unintended consequence is that then they write that one password to all of their passwords somewhere, hopefully on a post-it note, physical rather than online somewhere.

But what other Unintended Consequences do you see from password vaults?

Jeff: Well, so that's a good question.

I think some of the other things that you would see is you still don't-- I'm going to say reuse is always a big thing.

They say that distinctly, you should use-- I think that might be another unintended consequence because now you have the security of saying, "Okay. Well, where do I want to put my investment? I want to put my investment in the secure password that will secure my vault so I will commit that strong password to memory so that will effectively safeguard all of my other passwords."

Right? So I then make the false assumption that I can just set all of my other passwords with just lower things, whatever the minimum requirement is.

And maybe I'll reuse them if I don't want to keep generating more.

So you may create a false sense of security on the outside, depending on how the users interact with the vault.

And that's I think the other-- Aside from saying, "I'm going to write it down," and now I've got a post-it note that I keep in my wallet that has my vault password on it so when I open up on my phone, I can do that.

That's another one that I think is an unintended consequence that you create, like this, borrow a phrase, a security blanket around your passwords so you're less strict about how you construct your passwords for each of these individual sites.

Heidi: It's sort of like we all have a personal caring about this budget and where we allocate it is the only difference.

Jeff: Yeah.

Heidi: So changing gears, I was thinking about one of the interesting things that we've found with our product is people use it in ways that we didn't expect.

Are you seeing anybody use Okta in surprising, unexpected ways?

You're like, "Huh, we never planned for that, but okay."

Jeff: Yeah. I think of one of the biggest ways that we're seeing Okta used in ways is just in how people are customizing it.

I think it's always surprising to see how people will extend our product.

They'll hook it up to different workflows. They'll use our particular hooks to hook into other systems.

I always find that fascinating because it just speaks to the variations in business cases across different companies in the ways that they actually look and interpret how authentication can make their system and their user experience better.

And then I think the other thing is just how there's just ways that you can make the system really, really complex in ways that actually make a ton of sense.

We were looking at-- I find our multitenancy models to be the most interesting where a company was saying, "Well, I'm going to source a child organization for a customer and it's got to be set up in a certain way so they'll utilize our Terraform, they're using our APIs, they're using our SDKs to basically streamline this onboarding process."

And I just find that fascinating.

I've always had a fascination with Rube Goldberg devices. And I see that a lot in software, which is one of my interests that drew me to software, just seeing how all of these things can be chained together, how you can take response from system one, put that into system two, take that response from systems one and two, put that into system three and then actually see something flowing from end to end that looks amazing on the other side.

So I always find that's just intriguing. And when you open this up to customization through things like APIs and SDKs, you really just sort of open the world to all of these very use cases.

Heidi: Yeah. I think that's something that I enjoy too is--

Definitely, I would get up there and tell you how everything is LEGO and it snaps together neatly.

And in the real world, there's like a silly putty layer where you're like, "Okay, but I need that to turn into an angle that LEGO doesn't do. So we're going to smudge this stuff together and make it work."

And people do make it work and it drives business. So must be doing something right.

Jeff: Yeah.

Heidi: When you're thinking about what you're delivering, what are your upstream dependencies?

What do you have nightmares about going out? Is it S3? Or who do you rely on?

Jeff: So putting it in the layers of customization that we operate in.

So take something like our dev tools or Terraform.

We sit on top of an API that's managed by our platform.

So we really rely on the platform to make everything consistent and consumable and understandable.

The thing that keeps me up at night is the SDKs we're getting.

Are the customers happy with them? Right?

They're able to achieve their goals in the right ways or they're able to utilize authentication in the right ways.

Is our platform properly supporting how our customers are consuming?

Working in APIs, I think you always worry about interpretation.

I think this is one of the great things about API.

So you're putting in these building blocks, especially if you're building restful models.

You're basically saying, "Here's all the objects, how they relate to each other. And then go forth and build what you need."

But you do hope that the way that you've constructed that API is a little bit more intuitive, so customers are kind of using it in the way that you intend.

But you get these surprises, of course.

That's just the nature of business.

But one of the things I'm worried about with building these things out, it's like, am I putting my customers in the best possible scenario to where they can absorb these changes without having to do so much?

Working in APIs, I've taken a stance on not versioning as much as possible, looking to reimagine these things, because I believe in that.

That interpretation is its key, right?

I want to make sure the object model is right.

The object definitions are correct, and that it makes sense so that people can properly use it, get their jobs done and basically be super successful on the other end.

So boiling that down, the things that keep you up are making sure we've got the strong platform, we're exemplifying all of the great aspects of the platform through our SDKs and our dev tools, and then on the customer side, that they're able to interpret and use them effectively.

Heidi: That sounds like a lot of documentation.

Is that a thing that you've found needs to be scaled out or is that something your team does for themselves? How's that work?

Jeff: Yeah, that's actually a really great question.

I think the documentation is key.

I've been a developer myself, so I know how I approach documentation.

So I think having documentation that puts yourself at the keyboard as quickly as possible.

I like things like Swagger for APIs so I can read about it, try it out, understand it.

We have Postman collections for that as well.

But yes, documentation is key.

And one of the things that we've been working towards is to build our SDKs and samples to where we can get you at the keyboard faster in terms of the scenarios that will mean the most to our customers.

So really describing this in concrete terms like, "Here's the SDK for how you log in. Here's the SDK for how you employ MFA. Here's the SDK for how you extend your authentication to do social."

It's important to see that in action so that you can tangibly try it out and that leads to a more effective way of implementing it in your natural code.

On the periphery, we see documentation as a way in filling in some of those gaps that may be more nuanced in ways that we want to suggest doing certain things.

So we've actually tightly coupled step-by-step guides with our sample applications to sort of give you this kind of rich experience on how to bring this into your application.

So to answer your question, yes, documentation is essential.

I feel it's more symbiotic than anything else.

They live and breathe off of each other.

So having good samples leads to good documentation, having good documentation leads to samples, with this ultimate goal of having an effective experience for the developer on the other side.

Heidi: That's really excellent.

I think that it's sometimes something that people overlook.

Even when they're building APIs, they're like, "Well, the API, we did use OpenAPI or something to document it."

But it doesn't have that user story though, the why you would want to do this.

That is so key to finding the thing that you need to do in the moment.

Jeff: Yeah. And I think that's one of the lost value props of something like Postman.

When I've done APIs in the past, we would always construct our Postman collections to be kind of like journey-centric.

So like in our user API would say, "This is how you create a user. This is how you'd find a user. This is how you'd update a user."

So it actually walks you through and it uses the same responses so you're actually getting a feel of how I would construct my requests in my application just by exploring the API.

So I really believe in this API exploration as a way to explore the data model, but in the way that you intend, you have this opportunity to shape the customer's understanding if you phrased everything and organized everything in a way that sort of walks them through the way that you're envisioning they would walk through.

Of course, I think the beauty of this is it doesn't say that this is the prescriptive and only way to do it, but what it does is it sets them up to understand, "Okay. This is how the API was intended to use."

If I need to extend it in a certain way, I know what pieces of the request and response I would need for these others so I can start to interject another step if I need to have a detour, I need to do something else in my other app.

And I can do that safely and with some confidence that I'm not going to totally blow everything up to where I have to watch something more separately, have a ton of tests around it and feel less confident in the solution I'm developing or have to go to targeted support or something.

I can't just rely on what I can get out of the box to keep going.

Heidi: So the examples are sort of how you would use this and the documentation extends it, to how you would utilize it in sort of ever since.

Jeff: Yeah, exactly. Exactly.

So you have like this, "Hey, here's how the API is intended to be used," but you use the samples and documentation to say, "Here's a real world use case of what this would look like."

It's a little bit nuanced in that respect, I'd say, but yeah, that would be the intention.

You can literally walk through here's call one, call two, call three.

In the documentation, you're saying like, "It's more like... I guess like value-driven."

Like, "Here's how you log a user in. Here's how you create a user." Or something like that.

Heidi: So let's talk a little bit about breaking news in the recent time.

These attacks on water treatment plants, where it turns out that people have been already peeing into water treatment plants and basically leaving their workstations wide open.

What do we do about that as an industry?

I feel like we've left behind a lot of people who need security maybe even more than we do.

Jeff: Yeah. I think that this is an ever present question, right?

There's a couple of ways that I look at these when I read about them.

I'll try to find out like, "Okay. What was the entry point?"

In this case, it was people already peeing there, may or may not have been using a licensed software.

I think some people were using-- I think they mentioned TeamViewer in some instances, which does allow you to RDP and have live screen share.

But what was interesting about that case was the actual instrumentation change.

They were able to get into the console and then change basically the makeup of the water to put into some very dangerous state.

So I think what's interesting about that is that there's two real issues there.

There's obviously the perimeter defense, which is not allowing certain things to come in and blocking that out with a strong--

Maybe a data management policy strong, like a RDP policy, but there's this other part in there in the actual domain, the domain of the water treatment plant, which is, should someone be allowed to change the parts per million in a particular chemical to get to a dangerous level without having some catastrophic chain of approvals getting launched before the thing happens?

So the long story short in that is yes, I think that there's a lot of work to do to secure the periphery, but the way I've used security is you can have the strongest castle in the world, but if someone leaves the key on the doormat, you got a way in.

And I think that's where you can put a lot of these constructs in place that make it very inconvenient to get in, but it's hard to actually secure it all the way around.

You've got to put some safeguards in on the software side as well.

I think this is really open for debate, but one of the things I thought was immediate was well, first in the software side, we shall lock down how much you can add to a particular water supply that seemed to be low-hanging fruit that should either be prevented.

Heidi: Yeah. Let's put in a guard rail there.

Jeff: Yeah, exactly. Right. That should be prevented.

And then on the second part, yeah, it's like, let's go in and say, "Okay. Well, if you want to access these certain systems, you need two-factor."

Right? This is a big one. You need two-factor.

Some of the other things that I worked on in the past were maybe you need simultaneous key turns, right?

Some things you could utilize with phones.

You need to have someone in proximity with you physically, in proximity with you to make that change.

Those are things that you can do. But I think the biggest lift here is really adding an additional factor of something like a WebAuthn key or like a biometric on your phone or just an added factor of an SMS message and an OTP or another OTP site like a Google Authenticator.

Some of these things that you could add to not just assure that someone put in the right password, but that they also have another piece of collateral that identifies them.

Heidi: Let's back up and talk about different identity factors because not everybody is soaked in it the way we are. So what are the factors to confirm identity?

Jeff: Yeah. So it's usually based on different-- How do I say it?

It's like who you are, when you are, where you are, and kind of what you know.

What you know are what we are really familiar with.

These are passwords and then also the what you have, so like your ownership.

So ownership might be your phone through an SMS or through an app.

Also, could be email. The other ones, like the where you are and when you are, those are more soft based contextual authentication factors that you can look at.

I've worked in the past in some exploration of this.

You could look at routine patterns, like when do...

Like in the case of this water treatment plant, when do people usually make changes? If they get a request at three in the morning, see, well, that's really odd. So maybe I just don't allow it. Maybe I'll wait until normal business hours. And then the where you are too is using your location to actually confront. So if you're trying to do a change on this water plant remotely, maybe that's not recommended.

I know that things have changed in the pandemic.

So maybe you're actually geo-fencing around particular people's areas of interest.

So if something comes in from another place, you can either ask for more step up or do it that way.

But those are the ones that are really prevalent.

You also have these-- Obviously, the RSA keys and YubiKeys that are more hardware device specific that will allow you to log in.

There's a number of different factors.

And I think that's what makes this whole process really interesting is you don't have to choose just one.

Each of these can be used in the different scenarios to actually verify your identity.

Heidi: Yeah. I think I learned it as who you are, what you have, and what you know.

And another basic concept that we should probably back up and cover, especially in this context, is the difference between identity authentication and authorization.

So who you are when you log in and what you're allowed to do are different scenarios.

Jeff: Yes.

Kim: Which kind of gets at something you mentioned, should you be allowed to make certain changes?

Like you said, adding this certain element to the water past a certain mark, is this something you should be allowed to do?

Jeff: Yeah. So the authorization part is where you kind of bridge the gap.

So if you think about it, identity-- We can speak in terms of Okta.

We can recommend like, "this is how you should authenticate. These are best practices around authentication. These are best practices around defining identity."

So like how you would define a person in your system.

But identity kind of starts to bleed into the domain.

It's not just like-- Okta can't say, "Everyone should be defined as this."

You have different companies out there with different users that need to do different things.

They need to have a say in how they define what the identity looks like, and especially in authorization.

Authorization is the thing that really resides mostly in that domain, like what a person of a certain level with a certain set of responsibilities should be able to do a certain thing.

Okta is not going to be able to know all of that for all of its customers.

We really rely on having the things in there to say, "Sure, it's a protected if you use things like an OAuth, or you can use Scopes, which are ways to define authorization."

But still, this has to be kind of agreed upon with the customer.

So they have to really know what they want to allow a particular user after they're authenticated to do.

So I think that's where there's a lot of really-- The way I used to talk to my developers about it was like, "You should really think if the information that you've got or just live on the internet, would you be willing to share that with everyone? The answer is no, then you want to put it behind something where only authorized people can look at it."

But it wasn't like up to-- We were recommending this to other teams at my last job.

But even when we're talking to customers here at Okta, that's kind of where they have to go, so you have to decide what's the most important thing for you to keep secret and who should have access to it and you need to define your authorization around that construct.

Heidi: Yeah. That's really cool. And nerds will talk about this. It's AuthN and AuthZ.

So if you're trapped in a room full of security nerds, now you know what they're saying.

Jeff: Yeah.

Heidi: I think that one of the interesting things you mentioned--

Oh, well, talk to me a little bit about Okta's merger and what's going on.

Jeff: Oh yes. Well, we recently acquired Auth0.

So Auth0, some of you may know, or works in the same space.

They are very developer-focused and very pro code with their solutions.

But we actually saw that there's a lot of good synergy between the two companies and we're really excited that we're able to join forces now and really just disrupt the whole identity landscape.

I think there's a lot of really good energy about the things that we can do together.

And actually, it's just been really interesting to learn and talk to people from Auth0 about what their thoughts are on all of these identity concepts and everything.

It's one of those things that-- It happened, and actually, it's pretty cool to see how we're all coming together, and it's a very exciting time.

Heidi: So what would you say so far the most surprising outcome is?

What's the surprising thing you've learned?

Jeff: I say the most surprising thing is just how complimentary things are.

You would think like, "Oh, we're in the same space. This might be difficult or what not."

But there's just a lot of a common alignment and values too.

So it's really kind of cool to see.

So there's a lot of confidence that we've now just put two really great companies together and we're going to go out and do some really great things in this industry.