Understanding the Secrets of OAuth 2.0 with Aaron Parecki

Listen to this episode on:

Apple Podcasts | Google Podcasts | Spotify | Overcast | Pocket Casts

---

Check out the Book Club episode with Aaron Parecki, author of the book OAuth 2.0 Simplified, and Eric Johnson, Senior Developer Advocate at AWS, where they guide you through some of the main reasons to use the framework, that has already become an industry standard, and what it takes to build a secure web server.

The history of OAuth

Eric Johnson: Aaron, tell us, and this is kind of a broad-stroke question, but I want you to tell us the history of OAuth and specifically why it was created. Did people sit down and go, "Oh no, we need something and it's OAuth"? Lay that out for us.

Aaron Parecki: Definitely a bit of a broad question — could fill up a lot of time with this. But generally, the reason that OAuth was created had to do with this particular problem of using third-party apps to access APIs. Imagine early Twitter days where you have third-party developers writing applications to view and post to Twitter. The only way that could work is the application would have to ask you to enter your password in that application. That potentially means you're giving your Twitter password to some random developer, which is not great. Right?

There was also this very common problem where applications would want to get access to data that's in your Google account, your Google contacts, and they would have to ask for your Gmail password. And that, of course, gives them access to all of your Google account, not just contacts.

Eric Johnson: Right.

Aaron Parecki: So these things combined essentially meant that what we actually are looking for is a solution to let applications access some small part of your account while you are knowingly granting them that data, not actually granting them access to your entire account.

Key takeaway no. 1

OAuth was created because of the problems third-party apps had accessing APIs.

What are the major differences between OAuth 1 and 2?

Eric Johnson: Ok. All right, so the spec was... And I don't know if "spec" is the right word — the specification. But this idea of OAuth was created. There was a first version and in your book you talk about when that came out. Now we're up to a second version. So can you give us a little basis on, "Here's what was in the first version and here's what brought us to a second"? Can you kind of walk that history for us?

Aaron Parecki: Yes, for sure. OAuth 1 and its minor revisions, 1.0a and things like that, was all based around… It was the original framework for OAuth of the sort of delegated access pattern where, instead of giving the application your password, you are logging in at the OAuth server, and then giving it tokens, a sort of thing that represents access.

The way that OAuth 1 worked was that it required a secret, a client secret, for the application. That application had to have a secret of its own when it was deployed, and then it used that throughout the entire flow. It used it to start the flow, to ask for authorization and also when it was actually using the tokens that it was given.

Now that actually had some really cool security properties. It's great when that is possible, and we would like to be able to get back to that world in OAuth 2.

 Eric Johnson: Sure.

Aaron Parecki: The problem is that in OAuth 1, because it requires a secret, you just can't do it on a mobile phone or a single-page app.

Eric Johnson: Ok, that's what I was going to talk about. Please, go ahead.

Aaron Parecki: That's where it kind of breaks down. Where because OAuth 1 was created sort of at the beginning of the mobile explosion. Now mobile computing is just computing, but it was sort of the outlier then. It wasn't seen as a problem yet, but it turns out that you can't ship client secrets in a mobile app and have them remain secret because anybody can just extract them. That kind of breaks down the entire model of OAuth 1.

Eric Johnson: Right. In my world I build a lot of SPAs. I work with serverless, and we build SPAs and services on the backend. That was always interesting to me. Because when I first started getting to OAuth, and that's one of the reasons that made me really excited to do this interview — is because I was confused, "OAuth, I'm so confused." I think a lot of people are, and we'll talk about this a little bit later, but your book really laid it out and said, "Hey, it's not the black box mystery you think it is." I really want to say thank you for that. Because as I read it, there were a couple things like, "Oh. Oh. Oh, okay, that makes sense, now I understand that."

As I was working with this, I'm not a mobile developer. I've done some, but you really have to be desperate if you want me as your mobile developer. 

I didn't realize that you could so easily get a hold of that secret. I knew you could on a SPA because there it is, it's exposed right there in the JavaScript or wherever you're storing it. That was a really interesting point that had to be changed. So how was that changed in 2.0?

Aaron Parecki: Right. So it was clear that there was that problem. The other problem was that because of the way that that secret was used, in OAuth 1 it required going through a signature mechanism of economizing the request and sending all the parameters. That process was just complicated and people would often get it wrong. Effectively there was one library in every language that someone figured out, and then everybody just used that for everything.

Eric Johnson: Yes.

Aaron Parecki: It was not easily replicable code. Which is not really great, that's not a good spec. Right? A spec should be a blueprint for writing code that is easy to translate into code.

Eric Johnson: Agreed.

Aaron Parecki: That was one of the problems. These two things combined basically meant that, "Okay, let's do another revision." At that point I had been brought into the IETF, into the OAuth working group. The group started with a new spec, an OAuth 2 and the idea was, "Okay, we're going to change the assumptions we're starting with, and we're going to make it work from the beginning in these environments, like mobile apps and single-page apps."

The way that that worked at the beginning was effectively just not using a secret for those applications. There were two parts to that. There's when you are creating applications, a mobile app or a single-page app, you're just not going to get a client secret anymore because there's no point in pretending it's secret.

Eric Johnson: Sure.

Aaron Parecki: Second, access tokens are not going to require anything besides the access token to use them. We all understand this now, like this concept of, "Oh, you have this string, this is what you put in your authorization header and make a request." That's pretty normal. But that idea of switching from something that required signatures to just “we're just going to use a string as an access token,” that was a pretty big leap between OAuth 1 and OAuth 2.

That actually was the particular thing that the editor of the spec, Eran Hammer, had some very strong opinions about. He ended up quitting because of that, essentially. It's a very stressful job being an editor of a spec. But that was one of the things that he really sat on, "No, we need signatures. Just using a string as an access token is not enough."

From a theoretical security standpoint, that's absolutely correct. It is riskier to have just a bearer token, that's what they're called. That means that if you have the string, the token, that's all you need in order to make an API request. So if you hand it over to somebody else, they can make API requests that look the same as the real app making API requests which means attacks are harder to detect. If someone steals an access token, there's no real way to tell that it's been stolen. So that's sort of the problem with bearer tokens in practice. I would say it hasn't actually been a problem in most things.

Key takeaway no. 2

OAuth 2.0 is a complete rewrite of OAuth 1.0 from the ground up, sharing only overall goals and general user experience

What is the difference between Authentication (AuthN) and Authorization (AuthZ)?

Eric Johnson: Well, there's some other parts of the spec or other parts of OAuth 2, that help fight that. We'll climb into that in a little bit. Some points that you are making were really interesting to me. Before we jump into those, I want to take us back for a second.

It's been about a year and a half now that I've been kind of diving in my role at AWS, working with Cognito and some of our other ones, on how OAuth works. When I first started, in my head OIDC, JWT, OAuth, were all the same thing. Well, I've quickly learned they're not, right? JWT is not OAuth. Well, I'll let you explain it better than I can. But let's go basic for a second.

We hear these terms thrown around, we have AuthZ and AuthN. Right? And when you're someone like me and you're talking in public and you're not sure which one you mean, then it's just auth. Because you're like, "I'm not sure which I mean." So can you compare those, AuthN, AuthZ, what are they, what do they do?

Aaron Parecki: Ok. First of all, I absolutely hate those terms because they're too similar, and especially for non-native English speakers. I think it's a sort of cute thing that, like, the spec world has been like, "Oh, we're going to use these two terms because they sound the same and it's fun." But no, it's confusing and it does not do anything to help the situation.

Eric Johnson: Agreed.

Aaron Parecki: OAuth generally falls under AuthZ, and then OpenID Connect falls under AuthN. Right? That's where you'll see the breakdown. I like to think of it, instead of using those terms, as one is you're trying to get access to APIs, the other you're trying to figure out who the user is. Those are two totally different problems.

Eric Johnson: Agreed. So let's expand the words then. AuthZ is authorization, AuthN is authentication. Did I get that right?

Aaron Parecki: Yes.

Eric Johnson: I know you don't like the words, but that's what we hear. You compared them but could you talk about the differences.

Aaron Parecki: The idea of authorization is that you're trying to authorize a user or an application to act on behalf of a user. That's the OAuth use of authorization, right?

Eric Johnson: Ok.

Aaron Parecki: We're trying to say, "This user allows, is authorizing, this application to do these particular things on their account."

Eric Johnson: Ok.

Aaron Parecki: "This application is trying to access your friend list. This application is trying to post to your Twitter account. This application is trying to get access to your Google Drive files." That's all about authorizing that application.

Eric Johnson: Ok.

Aaron Parecki: What's actually going on on the wire is that the application is going to get some access token and use the access token to access APIs. When it does that, it actually doesn't need to know who the user is. The user's identity has nothing to do with whether or not that application is allowed to access those APIs.

So you can imagine that if you have an application that's going to let you upload files to your Google Drive, it just needs to be able to make an API request that says, "Upload this file." It doesn't need to know who you are. Right?

Authentication, on the other hand, or where the OpenID Connect part comes into it, is entirely explicitly about communicating who the user is to the application.

Eric Johnson: Ok.

Aaron Parecki: It's essentially a mechanism for figuring out, for communicating user information, like email address or name or user ID, to the application.

Eric Johnson: Ok. So if I were to say that in simple kind of Eric Johnson terms, I would say authentication is all about who you are and authorization is all about what you have access to.

Aaron Parecki: Yes.

Eric Johnson: Ok. When I first saw it, that was confusing to me. I was like, "Those are the same thing, authorization and authentication." But they're not and that's an important distinction. And it's important to understand that OAuth... And correct me if I'm wrong because I'm going to say this statement as if I'm an expert, but I'm not, you are. “OAuth is all about what you have access to.” Right? It is about the authorization, it is about saying, "As an application, you have access to this not based on who you are, but the authorization you've been given."

Aaron Parecki: Yes.

Eric Johnson: Did that make sense? Ok, excellent. Go ahead.

Aaron Parecki: It's about giving applications access to data. Right? It's not about deciding who can access what data within a system, it's not a permissions model, it's not how you do your own access policies. It's about giving a specific application access to some limited portion of a user's data.

Eric Johnson: Ok. That makes absolute sense. I think where I also was confused, and I think a lot of listeners would probably be confused, as well, a lot of times, are the pretty gray areas on some of the implementations that I've seen out there. We do use this authorization as almost, not an authentication, but... Well, yes, I guess it is kind of almost an access point. I guess that's where OIDC comes in, right? I think it originally was, "Hey, this is just authorization," but it certainly has kind of come in and become, "Hey, we're using this as an authentication in some way."

Aaron Parecki: If you want to go down that road, you can think of it as you are authorizing the application to allow it to know who you are. You're authorizing it to access your profile information.

Key takeaway no. 3

Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

Who is your target audience for this book?

Eric Johnson: There you go. Ok. Love the book, by the way. And again, it was really helpful. OAuth was the black box mystery to me, so this opened a lot of things up. So I want to kind of climb into the book, if we can, with the rest of our time here.

The first question I would ask is when you sat down to write this, who was the target audience for your book?

Aaron Parecki: So I actually went through a couple of iterations, honestly, because I had started the book quite a long time before it was actually published. But the target audience now is essentially people who are trying to actually work with OAuth systems more than just at the level of, "I'm trying to just throw a library into this and move on." If you're writing a library or writing an OAuth server or at all involved in the decisions behind doing things certain ways. If you are one of the decision-makers "Oh, we're trying to evaluate whether or not we should do X, Y, Z." That's really who it's for.

Would you recommend building your OAuth server?  

Eric Johnson: Ok. So let me ask you a question based on that. Because there's a huge section of the book that talks about building your own OAuth server. Would you recommend that to anybody? I mean obviously you would, it's in the book, I didn't mean to say it that way. But that's not something to take on lightly, for security reasons. Would you come to a company and say, "Build your own or use one of the many services that are available"? What's your approach on that?

Aaron Parecki: I would definitely not recommend building your own. And that's not just because I work at Okta, where we provide an OAuth server.

Eric Johnson: Sure.

Aaron Parecki: But it is not a small undertaking, for sure. And there's a lot of things that can go wrong, a lot of ways to get it wrong. A lot of those, thankfully, are documented in my book, also in the specs, also in many extension specs.It is a large undertaking.

So that said, there are sometimes reasons to build it. Like if you're building a small-scale API that's really just going to be like a self-contained thing, it actually ends up being more complicated to integrate it sometimes with an OAuth server. But it also very much depends on the situation. If you're supporting third-party developers or if you are just trying to do this for your own APIs. There are few reasons to actually go and build this stuff from scratch, as build an OAuth server from scratch.

Eric Johnson: Right.

Aaron Parecki: But one of the things I did do, did want to do in that book, is point out exactly what it takes to build one so that you know what you're getting yourself into if you think you're going to go down that road. I think too often people look at the specs and miss that, because it's written from sort of describing the client to OAuth server interactions and leaves a lot of the details of the OAuth server itself out of the spec because it's not necessary for the communication between the two. So people look at that and say, "Oh, I can do that, not a big deal," without really realizing actually what they're getting into. 

I wanted to lay out all the steps, "Here's what you need to know in order to build an OAuth server successfully so that hopefully you realize what you're about to do, what world of hurt you're about to be in." 

Eric Johnson: And I took that. As I was reading, and I'm not going to lie to you, there's a little niggling in the back of my head that said, "I might build a serverless version of this at some point." But it may already be out there. "Oh, yeah, I could do that." But I think what was interesting as I was reading, because, you get very detailed in this section, it's like, "Hey, in this, you know, verification, you should be asking these questions or showing this to your users," and stuff like that. There are a couple times I've had some that didn't do that and I would have liked to have known that.

 

I think that's where the book really became helpful, also looking at some of the implementations that I have seen and used that are in the wild, "Are they really covering all the bases?"

I'm going to say it again, I appreciate that because it kind of was like, "Okay, now I get why that is." And I want to kind of jump in. Just for users who may not understand OAuth, let's talk about some of the flows that are available, that are probably the most secure. In your book, and it was interesting, when I was looking at some of the OAuth documentation your name comes up everywhere. “Oh, okay, just click on this," they come back to your website a lot. So you're obviously an authoritative person in this and I appreciate that.

Key takeaway no. 4

Don't build your own OAuth server!

What is a grant type and how does it work?

Eric Johnson: So let's talk about some of the grant types. One, what does a grant type mean and how does that work?

Aaron Parecki: OAuth is modeled around this idea of grant types. The idea of the grant is the mechanism by which an application will get the access token. So the goal of an application in OAuth is to get an access token, that's how it's going to then go access an API.

Eric Johnson: Right, right.

Aaron Parecki: So a way to do that, and the way that it will do that, is called an OAuth grant. There are several OAuth grants described in the original spec, there's a few that have been added later, some have been removed. We try to recommend only the most secure, current best practices of those grants.

So the most common one that you're probably familiar with that you've used almost certainly, because everything uses it, is the authorization code grant.

Eric Johnson: Yes, yes.

Aaron Parecki: That is the redirect base flow where you are, on this page, you click a button, you get taken over to the OAuth server, log in there, then you get brought back. 

Eric Johnson: With a token, right? With a code.

Aaron Parecki: With a temporary code in the URL, which the application can then go and exchange for a token.

Eric Johnson: Ok. So then what happens?

Aaron Parecki: So that flow starts the application, goes over to the OAuth server, you log in, come back to the application with a temporary code, the app exchanges that temporary code for an access token, and then you're logged in and the app can access that API.

After the grant is complete, it does not matter which grant was used, effectively. The grant is just the very brief exchange of actually getting that token.

Eric Johnson: Ok. So, "Here's your token, go, do your thing." All right. We may or may not get into it, there's a couple tokens you can get back, an access token, an ID token. But there's a refresh token. That's, in a sense, another grant type, right?

Aaron Parecki: It is. And it's listed in the OAuth spec as another grant type, it's the refresh token grant.

Eric Johnson: Ok.

Aaron Parecki: The quick summary of a refresh token is that it's a way that an app can get new access tokens without doing the redirect-based grant again, without bothering the user. So the user has to be involved in that first grant, right?

Eric Johnson: Right, right. Authenticate for it.

Aaron Parecki: The refresh token is so that the app can get a token without the user being present. You might also hear it called offline access, where the app can work without the user being at the computer anymore. So it needs to get offline access to their account. And it will then get a refresh token so that access tokens don't have to last forever.

Eric Johnson: What was interesting to me in the book were some of the strategies. And before I even ask that, I'm going to make this statement and you can tell me if I'm right or wrong. Probably the most secure way of doing this is the authorization code grant, right?

Aaron Parecki: With PKCE.

Key takeaway no. 5

PKCE is the most secure way to do authorization code grant

What's the advantage of doing a short access token period but a long refresh token period?

Eric Johnson: With PKCE, which we'll talk about. When I saw PKCE in your book, I did not know what it was. Now you explain it fully, but I had never heard of that. It was really helpful. So authorization code with PKCE is the most secure way. And I'll come back to that in a second, but I want to talk about the refresh token. You have a couple of strategies, you talk about short token, or short access code expiration, long refresh code, etc

So you'll get a token and, like you said, just before it expires your app can refresh and get you back in, or even after it expires, you can get a refresh token to do that. What's the advantage of doing a short access token period but a long refresh token period?

Aaron Parecki: One of the good things but also challenging things about the spec is that it leaves a lot of these decisions open. If you're building or setting up an OAuth server, you get to decide how long your tokens last. You have an access token and a refresh token, and you get to decide the lifetimes of those. It's entirely up to you, there's very little guidance in the spec because it is actually very dependent on what you're building and the security considerations around it.

You might choose a short access token lifetime but a long refresh token lifetime because you don't want the risk of stolen access tokens. You want the risk of stolen access tokens to be diminished. If an access token is stolen, it only lasts for 10 minutes or something, right? Or if you're using an access token format where your APIs can validate the token without looking up anything externally, probably the most common is a JSON Web Token access token, then your APIs might be looking only at that string and not actually checking a database of valid users or applications. This means that the token is effectively a cache of the state of the system when it was issued. If your access tokens then last a really long time, you effectively have a really long cache — a window where the cache is essentially out of date, maybe out of date.

Eric Johnson: Ok, all right.

Aaron Parecki: You might be then acting on old information if you are using an access token that was issued a long time ago that is self-contained. So shorter token times means you reduce the window where that validation may be wrong.

Then you can set the refresh token lifetime to however long you want your users to not have to log in again.

Eric Johnson: Ok.

Aaron Parecki: I was going to say with shorter refresh tokens it means that when the refresh token expires, the only thing the app can do is start a flow again and get the user to log in again. 

Eric Johnson: Ok. So I'm going to think this out loud for a second. So if I'm a user, if I get a short token. If someone were to have gotten that token. We hope not, but if they do. They only have the window of that token to access my data. So that's going to lock that down. Now while my refresh is longer, if someone gets a hold of that, the minute the system detects two — that a refresh token is being used twice — then it kicks it out.

Aaron Parecki: Yes, that's one way to do it.

Eric Johnson: Ok.

Aaron Parecki: The other way is if the application does have a client secret, then the refresh token isn't useful by itself anyway.

Eric Johnson: Ok.

Aaron Parecki: But if they don't have a client secret, you're right. Then the best thing you can do is replays of refresh tokens.

Key takeaway no. 6

"Short token lifetimes" means reducing the window where the validation may be wrong.

PKCE grant type in OAuth and how to use it

Eric Johnson: Ok. That's a great segue, let's talk about client secrets for a minute. With the OAuth 2 spec, they're kind of removed, right? We're removing client secrets because we can't do them in SPAs, we can't do them in mobiles. There is some security that we can wrap around that. As I said I'd come back to it, is PKCE. So explain PKCE.

Aaron Parecki: Yes. With the authorization code flow, I stepped through a high level of it. The authorization code flow with the client secret is mostly secure, although it turns out that PKCE actually solves a very small attack even if you have a client secret still.

What PKCE does is PKCE basically creates a new secret for every request, for every initiation of the flow. When the app goes to start the flow, the app has to first create a new secret for that particular exchange. It uses that secret to calculate a hash of it that's sent out publicly. Then it has to use that secret when it goes and exchanges the authorization code.

Eric Johnson: Ok.

Eric Johnson: Ok.

Aaron: So effectively what it does is it means that the authorization code that gets returned in that response, without a client secret that could be used to get an access token. An attacker could steal that to get an access token. With PKCE it is no longer possible to steal it because the secret has actually never left the device during that whole exchange until it's actually used to get the access token.

Eric Johnson: Ok, that makes sense. So with PKCE, the onus is on the client to invoke. Because what I'm seeing and did some reading on this is... Go ahead.

Aaron Parecki: No, go ahead.

Eric Johnson: Ok. It's okay to tell me I'm wrong. "I'm never wrong," I had a T-shirt that says that, but sometimes I am. 

From what I'm understanding, if I build an OAuth server, I may support PKCE. It depends on the server, but I've seen a lot of them support them optionally. So if the PKCE is passed in, then implement it and use it the second time. What I'm driving at, is if that's the case, then the onus is on the client to say, "Hey, I'm going to implement that PKCE protocol," if that's the right word, "to use that." Does that make sense?

Aaron Parecki: Yes, that makes sense. Just a couple things to clarify there.

Eric Johnson: Ok.

Aaron Parecki: An OAuth server that supports public clients, like mobile apps and single-page apps, should always support PKCE. There's no good reason not to. So if they are letting public clients not use PKCE, that's definitely bad.

Eric Johnson: Ok. So it should be enforced...not just support PKCE, but enforce it?

Aaron: You should enforce it. Now for confidential clients, there are a lot that doesn't require PKCE or even don't support it. 

Eric Johnson: I'm going to interrupt you one second. For what kind of client did you say that?

Aaron Parecki: For confidential clients.

Eric Johnson: Ok.

Aaron Parecki: I've definitely seen OAuth servers that don't require PKCE or don't even support it. Now this is more recent guidance coming out of the OAuth group, but it turns out PKCE is actually important there, as well.

Eric Johnson: Ok.

Aaron Parecki: The attack that prevents it is too intricate to get into here, but there are videos on the Okta Developer YouTube channel if you're curious about diving into the nitty-gritty on that. But what it effectively means is that PKCE is a good idea even if you do have a client secret because it encapsulates and binds that one request end to end. It protects the flow even for confidential clients. Which effectively means all clients should just do it all the time.

But the point about whether the client is enforcing it or not, the reason for which PKCE is a great idea for all OAuth services support is the mechanism. The way that the mechanism actually works is that the authorization server gets the opportunity to deny requests that don't use PKCE. Whereas other solutions to these similar problems rely on the client developer to get it right and the OAuth server can't even tell if the client developer is doing it right.

Eric Johnson: Ok, that makes sense to me. So bottom line, use PKCE, pronounced "piksē". That makes complete sense to me.

Key takeaway no. 6

When using PKCE the authorization server has the opportunity to deny requests that don't use PKCE

Key takeaways from the book

It's been a great conversation. The last question I have for you. Once I read this book and talked with you, there's a billion questions I could ask. So we're best friends now, so prepare for that. What are some key takeaways that you want users to have, or readers to have? If you say, "If nothing else, I want them to understand this," what would you say?

Aaron Parecki: I would say focus on learning the authorization code flow with PKCE because that's just the default most secure way for the most different kinds of environments. Also, OAuth is not as complicated as you think it is.

Eric Johnson: Yes.

Aaron Parecki: There are some complicated parts, but it's not as bad as you think and it's worth learning a little bit in order to actually understand what's going on. And don't build an OAuth server.

Eric Johnson: Don't build your own. There's plenty out there and they're doing it well, right? So yeah, now, I agree. But I'm still going to do a serverless one maybe, we'll see. I'm not going to publish it or anything, but I just want to see if I can do it. 

I will tell you, and I know I said it already, but the book really opened up some of the questions I had. I was surprised that there is some flexibility in the spec and that it could kind of be user-dependent sometimes, or server, you know, whoever built the server. But it is a lot simpler than I thought, or it's not near as complex as I thought. I think sometimes we just don't explain it well and your book fixes that. So I really appreciate it, I really appreciate your time. I want to know where I can order that shirt. Obviously bigger than that one, so, you know, you'll have to send me a link and I'll order. Yeah. That's a cool shirt, so.

Aaron Parecki: I don't have these up anywhere yet, actually.

Eric Johnson: Aw.

Stay tuned for the second part of this episode. "Advanced OAuth and Pitfalls "- coming up soon.

---

About the authors

Aaron Parecki is a Senior Security Architect at Okta. He is the author of OAuth 2.0 Simplified, and maintains oauth.net. He regularly writes and gives talks about OAuth and online security. He is an editor of several internet specs, and is the co-founder of IndieWebCamp, a conference focusing on data ownership and online identity. Aaron has spoken at conferences around the world about OAuth, data ownership, quantified self, and home automation, and his work has been featured in Wired, Fast Company and more.

Eric Johnson is a Senior Developer Advocate for serverless applications at Amazon Web Services and is based in Northern Colorado. Eric is a fanatic about serverless and enjoys helping developers understand how serverless technologies introduces a major paradigm shift in how they approach building and running applications at massive scale with minimal administration overhead. Prior to this, Eric has worked as a developer, solutions architect and AWS Evangelist for an AWS partner company.

If Eric could be a Chief Happiness Officer, he wouldn’t have to do anything but show up as he is.