Securing ASP.NET Web APIs and HTTP Services
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Baier, Dominick
Modeling web services using the HTTP API approach has become pretty much the standard approach. This also means that these APIs must be ready for all the security scenarios around identity and access control. These range from simple username/password and service to service communication, over enterprise integration to token based authentication and delegated authorization. In addition we also have to deal with different client types likes native desktop or mobile clients, browser clients and classic web applications. Dominick shows you how this all comes together.
 Hi, welcome. Wow, that's the Scandinavian excitement. Okay, anyhow. I'm happy to be back here doing this talk and for those who have been here last year, I did a talk, I think with the same title like 12 months ago and I like to think of this as like a continuously deployed talk because I'm constantly changing it and adding stuff to it, removing stuff because we are learning, right? It's still in the dot net space at least, that's kind of a new technology. So 12 months ago, this wasn't even released. It was like three months before Microsoft released the API. So now today, we are three months before version two of the API. And the idea of this talk is basically to do a mixture of what do we have today and what will we get in three months. Okay, so I have a list of features that I want to show you that you know what's coming up and actually I want to skip some of the basics because you know, 60 minutes is not so much time. But if you go to Vimeo, there's the video from last year where you know, I basically talk about these things from the point of view from 12 months ago. Okay. Also very important, I think, is when you talk about web API security today, there is this thing called O of, yeah, this is protocol that is quite controversial right now. Since it's kind of hard to fit in all the framework stuff and the protocol into a single talk, I'm doing a separate O of talk later today at three o'clock in this room. So if you care about the gory details of this protocol and if you should use it or not, then come here three o'clock. Cool. So my name is Dominic. I guess the most important part here is he has my email address. If you have questions, you can write me an email or tweet me or whatever you want. So what are we going to do? We have a quick look at the HTTP security model and how we can implement that in web API. Then there's a new thing coming up in Microsoft's web stack called Owin, which is a hosting infrastructure that will be released in, you know, or is partially released already, but the full story will be done in three months time, which influences how you would do security in the future. We talk about the new web API pipeline, which gives you more options, how to do security, and then we talk about application scenarios. And basically, I want to take you on a journey from very simple applications that use web APIs to, you know, the way we build more complex systems and what are the challenges in between, how can web API help, and in the end, I'll show you something that shows how I can help. Good. So the big picture, um, is we are talking HTTP. Actually, we are talking HTTPS. So whenever we're doing security with web API, we have to use SSL. SSL is not optional. It's mandatory. Okay. That's for most security mechanisms we have today on HTTP. They rely on the transport protection. If you don't have transport protection, well, you shouldn't bother with all the login stuff. Yeah, right? You don't need it. Yeah. Everybody can read it on from your wire. The next thing which is kind of important is that Microsoft has split, even if it's called ASP.NET web API, it actually has nothing to do with ASP.NET. There are no common base class between the two frameworks. Yeah. So ASP.NET web API is hosting independent. You can take this thing and host it in an arbitrary process. Okay. And the host today is typically IIS. Or there's a self-host that ships with.NET or with MVC4. In MVC5, we will have a new host that has a number of interesting features. For example, that it's not bound anymore on running on.NET, for example. You can run it on mono, at least using the infrastructure that they provide. So that's kind of an important split. Yeah, because web API is just a bunch of classes which make up a framework and they can be hosted, which is different to ASP.NET, which was always kind of tightly bound to IIS. So let's start with this. I said it is very, very important that you always, always, always use SSL, right? And developers in SSL, they have sometimes have this love-hate relationship, yeah? These pesky exceptions throwing up, can't establish secure TLS channel, things like that. So I thought, let's ask Google, yeah? How to help me? How to handle SSL validation errors? And that's what I got back. Yeah, so you get plenty of guidance how to ignore SSL validation, but not so much guidance on how to do it correctly, okay? And especially with the new application architectures we are moving to, yeah? Web API, web APIs are perfect backends for mobile applications, right? So you are using them outside of the secure, you know, boundaries of your intranet where an admin actually controls all that stuff. So you're sitting in, you know, at the airport and, you know, accessing company resources, yeah? The guy next, or next table might be doing a middle attack against you, giving you a fake certificate and your app might never even notice why, well, because you ignored SSL certificate validation because, you know, that seems to be the popular thing, okay? So don't do that, okay? That's the thing I want to get out of the way here. For all the.NET developers out there, it's a class called service point manager. If you find that in your code like with full text search, there's something wrong. So the security model is really, really simple in HTTP, right? So we are sending everything in clear text over the wire. SSL protects, you know, from eavesdropping, replay attacks, gives us server authentication, integrity and that stuff. And whatever a server says, hey, you are not authorized to do that, you have to authenticate, it sends us back a 401, typically with a.dap,.dap authenticate header which tells us how we can authenticate, yeah? For example, basic, yeah? When you get back a scheme of basic here that the browser knows how to pop up a dialog box and you can, you know, type in your credentials, yeah? When you have typed in the credentials, the browser, if we use that as a client, will resend the request, yeah? And this time, put the credential on the authorization header and use the same scheme that came back earlier from the server. So they said, okay, I'm using now the basic scheme, that's the credentials, now, you know, I retransmit the data. And how that is done, well, as I said, typically it's the authorization header but there are other means like query strings, you know, don't use query strings, by the way, cookies are another typical thing how you transmit credentials. Now, how can we implement authentication in, in web API and authorization as well? And if you look at the documentation today, you will see this picture and that's the link where you can find that. So Microsoft has basically divided their pipeline into two parts, authentication which happens first, early, and authorization and afterwards the actual business logic which is in the controller. Now, when you want to do authentication today in web API, you have two choices and none of them are perfect, yeah? So one is you are writing an HTTP module, okay? That is an IIS extensibility point. The, I guess the advantage of that is it's a kind of a simple to use programming model. The disadvantage is you are bound to IIS. I said, web API is hosting independent. So what about now I want to take my web API and want to host it as an anti-service? Yeah, you are bound to IIS because you have host-specific investments, yeah? So the answer was, okay, if you want to do that, write a so-called HTTP message handler. And that is kind of a low-level interface in web API that gets to see all requests or responses, allows you to validate credentials, send back these status codes and headers and all these things. But you had something which is web API-specific, okay? And then there was the authorization filter. Basically, they called after authentication has happened, they called the authorization filter and that makes sure that the user has certain, you know, properties, claims that allow him to actually access the business logic. And again, the model wasn't perfect because you started implementing authentication as message handlers. There was a bit of an ordering issue. It wasn't really clear that when you add multiple handlers to a web API in which order they run or at least if multiple people add to that pipeline, for example. So it would have been nice if there would be a separate stage between message handlers and authorization filters that are specific for authentication. And Microsoft took that feedback and actually changed that. So first of all, the whole hosting thing has changed. As I said, the new hosting infrastructure that will be used by default with web API version two but is already used today by Signal R is called O-Win. It's the open, can't remember, open is the key. And the interesting thing is now that Microsoft, this O-Win thing is basically a specification how to tie together frameworks and hosts, okay? So that they can happily live together in the same process. And a number of open source frameworks are also using O-Win right now already or will use it in the future like Nancy, Fubu, ServiceSec and so on, which means that in the future you will be able to run all these things in a single process kind of keying off the same routing table almost. Yeah, you can select slash API goes to web API, slash disk goes to NancyFX, slash something will be your signal R hub to do the full duplex communication and so on. And for security, what that means is if you want to write authentication logic that needs to run across all these frameworks, you have to use the O-Win specific extensibility points, okay? And Microsoft will ship a bunch of them in the next version for JSON web tokens which I guess is the most important one, forms of authentication, Twitter, LiveID, Google, Facebook. So they are feature parity with what they have in MVC4 right now with this.NET OpenOff social logins. So they will reimplement all these things without.NET OpenOff from scratch as O-Win middleware and basically meaning Microsoft donates kind of all that code so all the frameworks you are seeing on that page can use it and your framework as well if you are in the framework business, you set up your stuff on O-Win, you will get this all for free, okay? So just to give you an idea how that new pipeline looks like, you see we have the host which is now O-Win, doesn't matter if it's IIS or something else, they use the same O-Win pipeline regardless of the host in the future and here you would implement a hosting framework independent cross cutting concerns like authentication, okay? Then when we transition into the web API we have message handlers which are still there which you still can use if you have existing code for message handlers, just reuse it, it will work, okay? The other new thing they added is before they actually run the authorization filters there is now an authentication filter. So the idea is now that in the future you will use message handlers for cross cutting concerns which are not necessarily security related, yeah? Like you want to inspect messages, maybe transformation, media type format is run in this early stage for example, yeah? So connect. If you want to do web API specific authentication write an authentication filter, if you want to do web API independent authentication write an O-Win middleware, okay? It's about choices I guess. So, oh, and just to make it clear as I guess can imagine the more you are on that side of the world the more generic your code will look like obviously because you need the right code that works with arbitrary frameworks. The more you move to that side of the world the closer you are to your business logic and the more you can, you know, write very specific code, yeah? So it depends really what you want, yeah? Just to give you an idea that's how middleware looks like in O-Win. As I said it's a kind of an abstraction, okay? Has anyone done Node.js in the room? So there's this concept of middleware, it's a pipeline. Basically you chain together functions, okay? And you call one function, it does its work and then it calls the next function, yeah? It's like the 8-bit pipeline just a little bit more down to earth. And just to give you an idea basically that's how they abstract the way HTTP. It's an addiction-navial string object, okay? In there you have things like verbs and URLs and headers and all that stuff, yeah? And then you work on that level and for example if you would authenticate someone you would look for the authorization header, you would pull out the credential, you would run your credential specific logic and if you are happy you would set the principle on another key in that environment dictionary and at some point there's other middleware who will take that and pick it up and move it to web API, okay? So just to give you an idea how low level that is but if you are in that business that you have to support multiple frameworks then you can work on that level. The traditional one was the message handler level. Again equally low level but you already have, you know,.NET objects here, HTTP request message and HTTP response message. So you're working at a slightly higher level here. And the idea was you get the request, you do whatever you want like authentication, you generate the response and you return it, okay? And I have a pretty popular framework out there called Think Textual Identity Model which does exactly that. It has a thing called the authentication handler which derives from delegating handler and it knows how to pass headers and query strings and cookies and client certificates and all that stuff and maps it to validation logic and then it does the authentication for you, the claims transformation, the session handling and setting the principle. So if that's all you need, that'll work today, that'll work tomorrow, O-Win is the version next thing, okay? So the other new thing that we'll have in that API is the authentication filter and you see now that we are so late in the pipeline now that we can have this semantics here. I can decorate controllers and action methods with attributes saying this controller needs this authentication method, that controller needs that authentication method. You can even go as granular as saying this action method needs that authentication, that's the delete method needs the client certificate, for example, yeah? So depending on your needs, you can go from very generic to very granular in the future or today as well but this stuff is new stuff, okay? So now that's authentication, yeah? The next thing that's happening afterwards after the user is authenticated, we have authorization and that nothing has changed here really. We have the authorized attribute, just putting it on something means the user has to be authenticated somehow, okay? We don't care too much how. You have to allow anonymous attribute where you can override this here saying like, okay, the whole controller needs authentication but this method here allows anonymous access, for example. And you can further specify it like saying this action here requires that the user is in a role called foo, yeah? And for everyone who knows me, I would say never ever do that, okay? Because what you're doing here is you're tightly coupling your business logic with security logic, yeah? And whenever the requirements change, who can call the delete method here, you will have to change your code, have to retest it, redeploy, you know, all that stuff. What you should do is rather abstract the way the security logic to move it out of the actual business code and that's what you do basically by deriving from the authorized attribute and implementing the is authorized method and implement your custom security logic inside of there so you have it out of your business logic. And typically you would do that in a separate assembly, meaning when the security logic changes, you can just update your logic in the attribute and redeploy that assembly but not the rest of the application, okay? And that's basically how I implement what I call claims-based authorization. That's another thing from FinTech identity model and what this basically does is it gets rid of all of the security information in the business logic itself. It just says, hey, you know what? This method here put which returns a customer, this updates customers, okay? And whenever someone calls that operation, I will call a separate authorization logic which says, hey, here's this guy with these claims, he's trying to update a customer. Is he allowed to do that? Yes or no? Okay? So what you do is you actually describe what the method is doing and not telling them who is allowed to call it, right? These are two separate concerns and I think you should model your APIs like that as well, okay? Questions so far? That's the pipeline, okay? Authentication host, authentication of API, authorization, business logic. And now we can build stuff on top of that. So we divide applications today, I guess roughly in two big, you know, buckets, yeah? Same domain and cross domain. Same domain means that the caller of the web API lives in the same domain as the web API itself. And that is very typically like, you know, an application, you render a page, this page does an HX style callback back to its own application with some web API, maybe doing some validation, maybe fetching data, you know, the cool kids call that spa today. Single page application and even if you might have more than one page. There's one issue which we have to think about when doing HX style or same domain applications called C-Serve attacks, okay? So but the idea is this, you are going to an application, you log in like forms of indication, for example, yeah? You go to a page, the page does a callback to a web API in the same application and the cookie that was set by forms of indication just flows back and forth now, meaning you are implicitly authenticated in the web API as well, okay? Let me quickly show you that. Here's a page which I have implemented, wow, the projector has a problem. So I was talking that on that side, it's better. So you see basically what this page is doing, it iterates over the identity, over the claims of the user and spits it out to a client browser. And the way I do that on that page is classic MVC style, I pass in the claims as a model into the view and I'm just rendering out the model here on the server, okay? The same thing, the same page here, just doing the client side approach would be this, there's no model here, yeah? And I'm actually from my page calling a web API here that returns the identity of the user, okay? Same idea, one is server rendered, the other one is using JavaScript to get the data while the page is being rendered on the client side. And the point being here is both pages should return the same results because it shouldn't make a difference from your application point of view if you're doing it server side or client side once as long as you stay in the same domain, okay? Oops. Let's run it. So I guess I have to move that also to the other side. Okay, can we see that? Yeah. Okay, so when I say identity server, this is using the server rendering version, yeah? So I have to log it. And here we are, we have two claims, my name and something I added like locally. So when I go now to the client here, what you should see is the same thing, it's just a little bit different. First the page renders and then the data will come because I'm doing the HX callback, okay? So in other words, this is like the it just works scenario, okay? But there is one issue here and that's called cross-site request forgery. When the application sends down that forms of indication cookie, yeah, it will happily send it back every time I'm doing a request to that same domain. That's how cookies work, yeah? But it also means, yeah, if I'm serving to a different site, yeah, or in a different process, yeah? And this website makes a request to my application I've been authenticated with already, the browser will send that cookie along as well. Okay, so when I, let's do this. On this other tab, yeah, I haven't authenticated, yeah? I'm accessing the web API directly. You see that? I'm authenticated. Okay? So in other words, you don't want that, okay? You don't want that some application from ChinaHackshack.com, yeah? Render some script on your browser which access another site where you are potentially authenticated and can impersonate you, okay? So you have to protect against that. And that is called NTCServe. Yeah? That's the problem. We go to the app, we authenticate, we get a cookie. Now we're going to an evil app that makes requests to the same application, we send you authentication cookie, okay? Now Microsoft has something built in. It's not part of the framework, but it's part of the Spark template in MVC4 and it's called the validate HTTP entry for token attribute, yeah? And what this thing is doing is basically this, yeah? So when you go to the application and it renders down the form which has all the JavaScript on it and so on, what they do is they render two additional things. One is a cookie which has a random or not a random number, but something that is cryptographically derived from something on the server, okay? But it has a so-called anti-fottery cookie that is rendered down and the form has an anti-fottery token as a hidden field, okay? And now and whenever you are doing a post back to that page, oops, you are basically posting back the cookie as well as the hidden field. And on the server, what this attribute is doing, it takes the cookie value, it takes the hidden field value, does some math on that and makes sure that they are coming from me, actually. And if that's not the case, it will reject the request, okay? And for web API requests, what you would send is, you would send the cookie as well and you would put that value of that hidden field as an HTTP header on your HX call. And again, when we come back to the application, what this attribute is doing is, it looks at the cookie, it looks at the header on your HX call, runs some math on that if they don't match, reject the request, okay? So in other words, the second tab doesn't know the cookie, but it doesn't know the hidden field on that form. So it can't send both, okay? And if you want to see that in action, just go to Visual Studio and create an empty Spark application and you will see that on the API controllers, you will have that attribute and it's like the source code is part of the template so you can have a look how it works and so on. But my point being here is, if you're building that type of applications, C serve is definitely a concern, okay? So protect yourself against that. Good. Questions on that? Okay. Now, I guess the much, much more interesting and more common applications you will build are so-called cross-domain applications, yeah? So even if you're, maybe your Spark application is same domain today, maybe at some point, because of the load on it, you want to separate the front end and the back end to different servers and then suddenly you're doing cross-domain calls, okay? And the whole cookie thing won't work anyways, so prepare for that. But the whole idea is cross-domain applications, they live in separate domains. One domain is here, one domain is there and that might be, you know, a browser, that might be a native application, that might be something and you have a different server where the web APIs live, okay? And suddenly you are in a whole new world of security scenarios. So you have to think about authentication because cookies don't cut it anymore, yeah? You have something called cause, which I will show you and what you ultimately want to do is doing something called token-based authentication and the next version of web API makes that much, much easier. Okay. So we have to authenticate our user somehow, right? And I guess the thing that, you know, is there forever works kind of, is called shared secret authentication, in other words, the client and the server share a secret and the client sends the secret to the server and if that secret matches with the database, he proves that he knows that secret. They're also called passwords, okay? That's, I guess, you know, that works. But there are some issues with that, yeah? For example, you always have to send that credential on the wire. Obviously, it's protected by SSL and so on, but the much bigger problem is that the password needs to be in the memory of the client for the whole session, okay? So you basically need to open that application, you type in your password and the client needs to hold on to the password as long as you're talking to the server, okay? And I mean, thinking of mobile applications, how much do users like to type in their 12 character password every time they start the application? So what do you do then? Store it on the client device in clear text? Because, you know, mobile devices don't have that much crypto. So yeah, you can do it, but it's not very, you know, it's kind of old school, yeah? Slightly better from a security point of view as so-called shared signatures, where you have like a shared key and the client signs the HTTP request, sends the request and the server signs it as well and makes sure that the signatures match, okay? And if you are able to sign the request with that secret, you have proved you know the secret, yeah? And one popular open source library for doing that is called Hock. Hock is from the guy that originally created OAuth 2. He left the whole committee and I will talk about that in detail later on, but one thing is what he did afterwards, he created this shared signature authentication mechanism called Hock, yeah? I mean, you have the same problems. You have to store that secret on the client, yeah? That might be okay for maybe company machines. That might be not so okay for tablets or for mobile devices or whenever you generally have limited trust in the security of the device the client is running on. Yeah. What you really want to do, obviously because you are here in my talk, is token based authentication, yeah? And the idea is so much better, yeah? The client has a password for example or some sort of secret. He goes to a token service. He gives him the token service. He gets back a token in return in exchange. The client can forget that secret from that point on, yeah? Erase memory. It's never been seen here, okay? And from that point on, we use the token to authenticate with the web API, okay? And the way this works on HTTP is basically you put that token on the authorization header and a very common scheme is just saying bearer and again what bearer exactly means come to my talk at three o'clock. Now this might be a steep curve for some people because you need basically a separate token service infrastructure. This thing must be highly available obviously because if this thing goes down, all web APIs go down and sit behind it and rely on the token issuing mechanism. So what I have since I think last year already and what web API will have in the next version is a built-in token endpoint. Basically, we're taking this token service and moving it into the web API itself. So when you want to get started with token-based authentication, you don't need that infrastructure to start with but you have the same semantics. You're calling first the token service that's built into the API, get a token, forget about the secret and use the token from that point on. And that token could be a long list token for example saying it's valid for one week. So users only have to type in their password once a week. Google does it every two weeks for example. So the idea is this, you are going to a special endpoint here slash token typically, you authenticate, you get back a token and now you use the token to authenticate. I'll show you my implementation as I said in the next version of that API it's built in. So let's run fitler and let's open this. And I guess again I have to move it here. So what you're seeing here is first I'm making a round trip to the service, authenticate and get back to this long string. That's the session token. Okay. And from that point on I'm using session token to call the service and again what the service is doing is it's just echoing back my identity information. Okay. So let's press F12 here. So you see the first request, how much does that? Like this. You see the first request goes to the token endpoint. I'm authenticating here and, hold on. Yeah. And here we get back this access token. It's basically a JSON data structure which has two values access token and expires. And from that point on we just use the access token. So from here on I'm making the real calls to the business logic and you can see that we're using the session or the access token. From that point on my client doesn't need to know the password anymore. And I don't need to store it anymore on the client device which is I guess an important message here. Okay. Make sense? Good. I probably don't have the time but just recently I saw a presentation at the beach. So make sense? Okay. Okay. Now that was a C sharp client. Okay. Now let's do exactly the same thing in JavaScript to show you another interesting problem. So let's actually do this open the network thing here. So this is basically the moral equivalent of the C sharp client I just wrote. Okay. It's basically something that's a credential to the server getting back a session token and tries to use the session token afterwards. Yeah. So let's run that. Bang. It fails. Yeah. And what it does is it sends this options request here and this is basically a thing called course cross origin resource sharing. So this website tries to call a web API living in a different domain and browsers don't allow that. Okay. Otherwise you could do dangerous stuff. But given that this is kind of a popular scenario that you actually want to do that. Yeah. There's a specification for that called course which controls how you can do these cross origin call in the browser context. Okay. And when we look here at the console, what it actually says is local host is not allowed by access control. Okay. That means something has prevented to make the cross origin call. Yeah. And the way this works is this. Basically the JavaScript living in one domain tries to call the service in another domain. We what the browser is doing under the covers is first sending an options request saying, Hey, I have code here that tries to access you and it's coming from that origin and it tries to do a post. Are you cool with that? Yeah. And now the web API needs logic saying, do I allow requests from that domain? Yeah. And if he is cool with that, yeah, he says, okay, I allow that domain. I allow that method. I allow these headers and it's very granular what you can do here. And then afterwards the browser will do the actual request. If this here won't return or succeed, the browser will just stop here. That's the error you've just seen. Okay. Now the API version one doesn't include an implementation for course. That's again something we have implemented and there's a message handler, the course message handler. And obviously this is the demo mode configuration here. Yeah. All but what you can specify here things like I allow request server one, two and three, I allow post and put and I allow the accept content header, but not the, I don't know, whatever header. Yeah. So you can go very granular here and you know, just by enabling that, I can read the request. And now it actually worked. Okay. Because now there's a piece of code running in that API that understands the options request can evaluate it against the rules engine. So to speak and then send back the right response to that and allow that client access. So the good news here is that Microsoft liked our implementation so much that we are now moving into system.web with that. So basically they took our code. Yeah, thank you. Took our code and it's now system.web.course and actually all the credits go to Brock Allen, good friend of mine who did the actual implementation. Okay. And the way this works in the next is that you have a new attribute called enable course. You put it on the controller, say I allow these origins, these headers and these verbs. And that can be also stars in there if that's too granular for you. Yeah. But that's how it will work in the next version of the API. Okay. Move on. The next scenario that I'm seeing more and more and more in the last 12 months going to our clients is obviously you have architectures, way model things as a web API and you have many clients. Yeah. For example, server rendered.net clients, HTML5 JavaScript type of clients and obviously all these native clients running on different operating systems like desktop, mobile and so on. And obviously if your application gets that complex, then maybe the built in token endpoint doesn't cut it anymore, right? You need more control. You want to say like, well, this client gets access to these resources, that client gets access to different resources. Maybe this client needs to authenticate using a web browser. That client needs to authenticate using some different mechanism. So baking all that into your actual web API becomes a little bit of a maintenance problem. And that's where we factor out as always, we put a layer of abstraction in between and that's called the authorization server and that's actually a term from OAuth 2. And the idea is that you basically take all that logic, who is allowed to access what with which authentication method and blah, blah, blah, blah, blah and move that to a separate server and that takes care of it. Okay? And then basically the client goes first to the authorization server, requests the token, gets the token, access the web API. And that is actually covered by the OAuth 2 specification, which I will talk about in detail later on, yeah? But the whole idea is that you can come to an application architecture where you take a bunch of endpoints, a bunch of web APIs and group them together to something called an application. Okay? That is a logical grouping of endpoints and you define what type of resources are inside of that application. Yeah? Maybe your application is a user management application and you say, I can delete users, I can add users, I can, you know, add them to roles, I can search for them, blah, blah, blah, blah. Yeah? So basically you come up with your own domain specific things of what you can do in that application. Yeah? And now the OAuth protocol defines basically how a client can go to the authorization server and can ask for permissions. Yeah? I want to be able to search and read in that application. And now you can hang off rules and what you get back is an access token. And what the access token contains is basically who is the issuer, for which application is this token for, how long does it live, who is the user, who is the client and what are they in combination allowed to do in the application. Okay? That's your cost-claimed authorization and then inside your code you're doing your fine-claimed authorization going from there. Okay? Now the issue was that there is nothing built in or pre-built into.NET or, you know, or even products are not that common for that. So what I've been doing the last four weeks, I've been heads down basically implementing that stuff here. And what I want to do is I want to show it to you for the first time in public. Yeah? So bear with me. It might break. Yeah? But the whole idea is, let's do this, go here. You have this thing called Texture Authorization Server. And that goes hand in hand with, you know, Identity Server. So we don't only authorization here. We don't do authentication. Yeah? And basically what you can do is you can configure. That means I have to authenticate with some identity provider. That could be anything. Yeah? That could be, you know, Forms, Login, Google, Facebook, ADFS, Access Control Server, Windows, Azure, AD, whatever you want to connect to it. And then you have now this notion of an application. Okay? So we can create an application, give it a name, NDC, demo, give it some entry point in the URL namespace, NDC. That's the audience claim that will go in the token. So the recipient knows for whom this token is for. Yeah? We can give it some description. Can have a logo. Yeah? I can set a signing key. Do I want to do symmetric signatures, asymmetric signatures? I can specify other stuff like, do I want to require the user to give consent when the application asks for permission, stuff like that? And then I can save it. Okay? And now I can define scopes. So we have scopes here like your read scope. Yeah? And what? Scopes. Read. Oh, it's required. And the delete scope, for example, yeah? Delete. If something is really important for you, can emphasize it. So when the user clicks the, I allow that, he sees that emphasize on the screen, yeah? Saying, hey, that's something, you know, you should take pay attention to. And then you can per scope decide which of your clients will be allowed to request permission for that scope. Yeah? So maybe your corporate internet application can request delete permissions, but your iOS app can't, for example. Okay? So basically you can hang off permissions from there. And you can also define clients. Yeah? You can add a new client. You can tell which O of flow are they allowed to use. If they are using something that requires, you know, a callback, you can register the redirect you arise, you can call them back. So it allows you to pretty tightly lock down what this thing is doing. And now let me show you how it looks like in action. So let's run an application here called flows and O of defined so called flows that that's basically an orchestration how clients can request tokens. And again, for the gory detail come later to my talk. But one flow is the so called code flow. And that's for that application client. So this is a web application. It needs to talk to a web API on behalf of the human that's sitting in front of the browser. Okay? So what it does is basically it it goes to the authorize server, the user signs in. And now based on the definitions you did in the UI, you get this constant screen here saying, Hey, this client here tries to access an application called user management and it request the read and the search permission. Do you want to allow that? Yeah. And that screen is optional. So if you're more like an intro style of stereo, you can turn it off that this is a silent consent if you want that. But if I press allow, I come back to the application get a so called authorization code can exchange that code with an access token. And now with this access token, the application can actually call the web API. Okay? And it can store the access token. And this access token can be renewed. I think called refresh tokens. And again, we'll talk about that in a lot of detail later on. And at some point, the user decides he's not happy anymore that application accessing his data, it can go to kind of a self service portal, delete the access. And the next time the application tries to renew the token, it will fail. Okay? So that's how it looks like for web applications. If you're doing a client application, like a native application, for example, what you typically do is you open a web view. Yeah, so you're basically embedding a browser into a window in your application, which opens that constant screen, the user clicks yes. And then there's some communication going on between the web view and the client application to send back the token. And from that point on, the client application can access the token. Yeah. So when I do request token, I'm opening a web view here. And that's actually quite interesting. That's a new API in Windows 8, an operating system API that gives every application this feature of open and embedded web view. And that's kind of a special web view here because the calling application can't intercept keystrokes and stuff like that. And also it doesn't have access to cookies that are shared with desktop IE, for example. So when I sign in here, I see the same constant screen. This time I only ask for read. And by the way, I could even uncheck that here. And now the application has the token and can access the web API. And I'm just echoing back the claims here. Okay? For the last thing, I guess, is that you can do that all without user interaction. That is what comes closest to W's trust if you have done that in your past. Where basically the client itself has the credentials of the user and sends them to the authorization server and gets back a token in response. Okay? Without all the user interaction stuff. Yeah. And just to show you that this is actually used, yeah, so here is the Twitter application, which is opening a web view, right? And that's the constant screen. So I'm logging in here and say, authorize app. And from that point on, the Twitter client can access the Twitter data on my behalf. Okay? And the other approach, the one without the user interaction in the web view is done by Dropbox, where they collect the credentials directly, take these credentials, go to the authorization server, get back a token in response and use the token to access Dropbox. Okay? So that is really the pattern that you want to, that you want to prefer. Once your application is kind of in that category where you have many web APIs, many clients, users using different clients, maybe even throughout the day, you know, like, like maybe at daytime, they are in the intranet and taking like a corporate, officially blessed client application, yeah, which does all kinds of things. But on the road, they have their, you know, their mobile device with them where you have like a company deployed mobile application, which maybe has less access because, you know, just in case this thing gets stolen, we have some, you know, backup plan that, you know, you can't delete everything with that, whatever, yeah? Or maybe you have third parties building on top of open APIs that you are building, and then you can't control them in any way. But the way you can, you know, manage all that is by having the abstraction of an authorization server and application scopes and access tokens. Okay? And with that, you can, you know, kind of get a better handle on these kind of complex scenarios. Okay? So that's what I want to show you. You're seeing it here first. Actually, you know, like in a museum when you unveil a statue, I should do one last thing. I should do public. So here, settings, go to the scary part. And, oh, holy crap. I didn't test it, obviously, yeah? So where's GitHub? GitHub. Yeah, here we are. It's public, okay? So if you like that approach, thank you. If you like that approach, use it. It's in a very stage. And by the way, I also have written a little bit of documentation already, yeah? It's a little bit. Try it out. Give me feedback. There's an issue tracker. If you have ideas, you know, feature ideas, problems, whatever, give us feedback. And yeah, it's now public. We can shape this thing, okay? And I think it's tremendously useful for building these applications. Cool. So I guess to sum it up, we went from a very simple model from, you know, username passwords to having tokens instead, yeah? Having the authorization server inside the actual application to factoring out to a separate authorization server, to having a management system for these types of applications. You've seen C-Serve, which is something you should care about. My best advice is go away from cookie-based authentication. The next version of the Spark template in Visual Studio 2013 will be a Spark template without cookies. It will use the exact approach I just showed you, authorization server, over off flow, password in, token out, no cookies anymore, okay? So that's my advice. If you go cross domain, get friendly with course, yeah? You can't escape it if you are in the browser. And otherwise, yeah, think about your architecture in terms of access tokens. That helped me tremendously securing them once they got more complex and so on. Any questions? Yeah? That's being worked on right now, but nothing official yet. I can't say it's coming, but I think it's coming. Otherwise, it would be not too hard to write it yourself. If it's not coming, ping me, I will write it for you, okay? Okay, then thanks for your time and see you later, hopefully. Thank you.
 Hi, welcome. Wow, that's the Scandinavian excitement. Okay, anyhow. I'm happy to be  back here doing this talk and for those who have been here last year, I did a talk, I  think with the same title like 12 months ago and I like to think of this as like a continuously  deployed talk because I'm constantly changing it and adding stuff to it, removing stuff  because we are learning, right? It's still in the dot net space at least, that's kind  of a new technology. So 12 months ago, this wasn't even released. It was like three months  before Microsoft released the API. So now today, we are three months before version  two of the API. And the idea of this talk is basically to do a mixture of what do we  have today and what will we get in three months. Okay, so I have a list of features that I  want to show you that you know what's coming up and actually I want to skip some of the  basics because you know, 60 minutes is not so much time. But if you go to Vimeo, there's  the video from last year where you know, I basically talk about these things from the  point of view from 12 months ago. Okay. Also very important, I think, is when you talk  about web API security today, there is this thing called O of, yeah, this is protocol  that is quite controversial right now. Since it's kind of hard to fit in all the framework  stuff and the protocol into a single talk, I'm doing a separate O of talk later today  at three o'clock in this room. So if you care about the gory details of this protocol and  if you should use it or not, then come here three o'clock. Cool. So my name is Dominic.  I guess the most important part here is he has my email address. If you have questions,  you can write me an email or tweet me or whatever you want. So what are we going to do? We have  a quick look at the HTTP security model and how we can implement that in web API. Then  there's a new thing coming up in Microsoft's web stack called Owin, which is a hosting  infrastructure that will be released in, you know, or is partially released already, but  the full story will be done in three months time, which influences how you would do security  in the future. We talk about the new web API pipeline, which gives you more options, how  to do security, and then we talk about application scenarios. And basically, I want to take you  on a journey from very simple applications that use web APIs to, you know, the way we  build more complex systems and what are the challenges in between, how can web API help,  and in the end, I'll show you something that shows how I can help. Good. So the big picture,  um, is we are talking HTTP. Actually, we are talking HTTPS. So whenever we're doing security  with web API, we have to use SSL. SSL is not optional. It's mandatory. Okay. That's for  most security mechanisms we have today on HTTP. They rely on the transport protection. If  you don't have transport protection, well, you shouldn't bother with all the login stuff.  Yeah, right? You don't need it. Yeah. Everybody can read it on from your wire. The next thing  which is kind of important is that Microsoft has split, even if it's called ASP.NET web  API, it actually has nothing to do with ASP.NET. There are no common base class between the  two frameworks. Yeah. So ASP.NET web API is hosting independent. You can take this thing  and host it in an arbitrary process. Okay. And the host today is typically IIS. Or there's  a self-host that ships with.NET or with MVC4. In MVC5, we will have a new host that has  a number of interesting features. For example, that it's not bound anymore on running on.NET,  for example. You can run it on mono, at least using the infrastructure that they provide.  So that's kind of an important split. Yeah, because web API is just a bunch of classes  which make up a framework and they can be hosted, which is different to ASP.NET, which  was always kind of tightly bound to IIS. So let's start with this. I said it is very,  very important that you always, always, always use SSL, right? And developers in SSL, they  have sometimes have this love-hate relationship, yeah? These pesky exceptions throwing up,  can't establish secure TLS channel, things like that. So I thought, let's ask Google,  yeah? How to help me? How to handle SSL validation errors? And that's what I got back. Yeah,  so you get plenty of guidance how to ignore SSL validation, but not so much guidance  on how to do it correctly, okay? And especially with the new application architectures we  are moving to, yeah? Web API, web APIs are perfect backends for mobile applications,  right? So you are using them outside of the secure, you know, boundaries of your intranet  where an admin actually controls all that stuff. So you're sitting in, you know, at  the airport and, you know, accessing company resources, yeah? The guy next, or next table  might be doing a middle attack against you, giving you a fake certificate and your app  might never even notice why, well, because you ignored SSL certificate validation because,  you know, that seems to be the popular thing, okay? So don't do that, okay? That's the thing  I want to get out of the way here. For all the.NET developers out there, it's a class  called service point manager. If you find that in your code like with full text search,  there's something wrong. So the security model is really, really simple in HTTP, right?  So we are sending everything in clear text over the wire. SSL protects, you know, from  eavesdropping, replay attacks, gives us server authentication, integrity and that stuff.  And whatever a server says, hey, you are not authorized to do that, you have to authenticate,  it sends us back a 401, typically with a.dap,.dap authenticate header which tells us how  we can authenticate, yeah? For example, basic, yeah? When you get back a scheme of basic  here that the browser knows how to pop up a dialog box and you can, you know, type in  your credentials, yeah? When you have typed in the credentials, the browser, if we use  that as a client, will resend the request, yeah? And this time, put the credential on  the authorization header and use the same scheme that came back earlier from the server. So  they said, okay, I'm using now the basic scheme, that's the credentials, now, you know, I  retransmit the data. And how that is done, well, as I said, typically it's the authorization  header but there are other means like query strings, you know, don't use query strings,  by the way, cookies are another typical thing how you transmit credentials. Now, how can  we implement authentication in, in web API and authorization as well? And if you look  at the documentation today, you will see this picture and that's the link where you can  find that. So Microsoft has basically divided their pipeline into two parts, authentication  which happens first, early, and authorization and afterwards the actual business logic which  is in the controller. Now, when you want to do authentication today in web API, you have  two choices and none of them are perfect, yeah? So one is you are writing an HTTP module,  okay? That is an IIS extensibility point. The, I guess the advantage of that is it's  a kind of a simple to use programming model. The disadvantage is you are bound to IIS.  I said, web API is hosting independent. So what about now I want to take my web API and  want to host it as an anti-service? Yeah, you are bound to IIS because you have host-specific  investments, yeah? So the answer was, okay, if you want to do that, write a so-called  HTTP message handler. And that is kind of a low-level interface in web API that gets  to see all requests or responses, allows you to validate credentials, send back these status  codes and headers and all these things. But you had something which is web API-specific,  okay? And then there was the authorization filter. Basically, they called after authentication  has happened, they called the authorization filter and that makes sure that the user has  certain, you know, properties, claims that allow him to actually access the business  logic. And again, the model wasn't perfect because you started implementing authentication  as message handlers. There was a bit of an ordering issue. It wasn't really clear that  when you add multiple handlers to a web API in which order they run or at least if multiple  people add to that pipeline, for example. So it would have been nice if there would  be a separate stage between message handlers and authorization filters that are specific  for authentication. And Microsoft took that feedback and actually changed that. So first  of all, the whole hosting thing has changed. As I said, the new hosting infrastructure  that will be used by default with web API version two but is already used today by Signal  R is called O-Win. It's the open, can't remember, open is the key. And the interesting thing  is now that Microsoft, this O-Win thing is basically a specification how to tie together  frameworks and hosts, okay? So that they can happily live together in the same process.  And a number of open source frameworks are also using O-Win right now already or will  use it in the future like Nancy, Fubu, ServiceSec and so on, which means that in the future  you will be able to run all these things in a single process kind of keying off the same  routing table almost. Yeah, you can select slash API goes to web API, slash disk goes  to NancyFX, slash something will be your signal R hub to do the full duplex communication  and so on. And for security, what that means is if you want to write authentication logic  that needs to run across all these frameworks, you have to use the O-Win specific extensibility  points, okay? And Microsoft will ship a bunch of them in the next version for JSON web tokens  which I guess is the most important one, forms of authentication, Twitter, LiveID, Google,  Facebook. So they are feature parity with what they have in MVC4 right now with this .NET OpenOff social logins. So they will reimplement all these things without.NET OpenOff from  scratch as O-Win middleware and basically meaning Microsoft donates kind of all that  code so all the frameworks you are seeing on that page can use it and your framework  as well if you are in the framework business, you set up your stuff on O-Win, you will get  this all for free, okay? So just to give you an idea how that new pipeline looks like,  you see we have the host which is now O-Win, doesn't matter if it's IIS or something else,  they use the same O-Win pipeline regardless of the host in the future and here you would  implement a hosting framework independent cross cutting concerns like authentication,  okay? Then when we transition into the web API we have message handlers which are still  there which you still can use if you have existing code for message handlers, just reuse  it, it will work, okay? The other new thing they added is before they actually run the  authorization filters there is now an authentication filter. So the idea is now that in the future  you will use message handlers for cross cutting concerns which are not necessarily security  related, yeah? Like you want to inspect messages, maybe transformation, media type format is  run in this early stage for example, yeah? So connect. If you want to do web API specific  authentication write an authentication filter, if you want to do web API independent authentication  write an O-Win middleware, okay? It's about choices I guess. So, oh, and just to make  it clear as I guess can imagine the more you are on that side of the world the more generic  your code will look like obviously because you need the right code that works with arbitrary  frameworks. The more you move to that side of the world the closer you are to your business  logic and the more you can, you know, write very specific code, yeah? So it depends really  what you want, yeah? Just to give you an idea that's how middleware looks like in O-Win.  As I said it's a kind of an abstraction, okay? Has anyone done Node.js in the room?  So there's this concept of middleware, it's a pipeline. Basically you chain together  functions, okay? And you call one function, it does its work and then it calls the next  function, yeah? It's like the 8-bit pipeline just a little bit more down to earth. And  just to give you an idea basically that's how they abstract the way HTTP. It's an  addiction-navial string object, okay? In there you have things like verbs and URLs and headers  and all that stuff, yeah? And then you work on that level and for example if you would  authenticate someone you would look for the authorization header, you would pull out the  credential, you would run your credential specific logic and if you are happy you would set  the principle on another key in that environment dictionary and at some point there's other  middleware who will take that and pick it up and move it to web API, okay? So just to  give you an idea how low level that is but if you are in that business that you have  to support multiple frameworks then you can work on that level. The traditional one was  the message handler level. Again equally low level but you already have, you know,.NET  objects here, HTTP request message and HTTP response message. So you're working at a slightly  higher level here. And the idea was you get the request, you do whatever you want like  authentication, you generate the response and you return it, okay? And I have a pretty  popular framework out there called Think Textual Identity Model which does exactly that. It  has a thing called the authentication handler which derives from delegating handler and it  knows how to pass headers and query strings and cookies and client certificates and all  that stuff and maps it to validation logic and then it does the authentication for you,  the claims transformation, the session handling and setting the principle. So if that's all  you need, that'll work today, that'll work tomorrow, O-Win is the version next thing,  okay? So the other new thing that we'll have in that API is the authentication filter and  you see now that we are so late in the pipeline now that we can have this semantics here.  I can decorate controllers and action methods with attributes saying this controller needs  this authentication method, that controller needs that authentication method. You can  even go as granular as saying this action method needs that authentication, that's the  delete method needs the client certificate, for example, yeah? So depending on your needs,  you can go from very generic to very granular in the future or today as well but this stuff  is new stuff, okay? So now that's authentication, yeah? The next thing that's happening afterwards  after the user is authenticated, we have authorization and that nothing has changed here really. We  have the authorized attribute, just putting it on something means the user has to be authenticated  somehow, okay? We don't care too much how. You have to allow anonymous attribute where  you can override this here saying like, okay, the whole controller needs authentication  but this method here allows anonymous access, for example. And you can further specify it  like saying this action here requires that the user is in a role called foo, yeah? And  for everyone who knows me, I would say never ever do that, okay? Because what you're doing  here is you're tightly coupling your business logic with security logic, yeah? And whenever  the requirements change, who can call the delete method here, you will have to change  your code, have to retest it, redeploy, you know, all that stuff. What you should do is  rather abstract the way the security logic to move it out of the actual business code  and that's what you do basically by deriving from the authorized attribute and implementing  the is authorized method and implement your custom security logic inside of there so you  have it out of your business logic. And typically you would do that in a separate assembly,  meaning when the security logic changes, you can just update your logic in the attribute  and redeploy that assembly but not the rest of the application, okay? And that's basically  how I implement what I call claims-based authorization. That's another thing from FinTech identity  model and what this basically does is it gets rid of all of the security information in the  business logic itself. It just says, hey, you know what? This method here put which returns  a customer, this updates customers, okay? And whenever someone calls that operation,  I will call a separate authorization logic which says, hey, here's this guy with these  claims, he's trying to update a customer. Is he allowed to do that? Yes or no? Okay?  So what you do is you actually describe what the method is doing and not telling them who  is allowed to call it, right? These are two separate concerns and I think you should model  your APIs like that as well, okay? Questions so far? That's the pipeline, okay? Authentication  host, authentication of API, authorization, business logic. And now we can build stuff  on top of that. So we divide applications today, I guess roughly in two big, you know,  buckets, yeah? Same domain and cross domain. Same domain means that the caller of the web  API lives in the same domain as the web API itself. And that is very typically like, you  know, an application, you render a page, this page does an HX style callback back to its  own application with some web API, maybe doing some validation, maybe fetching data, you  know, the cool kids call that spa today. Single page application and even if you might have  more than one page. There's one issue which we have to think about when doing HX style  or same domain applications called C-Serve attacks, okay? So but the idea is this, you  are going to an application, you log in like forms of indication, for example, yeah? You  go to a page, the page does a callback to a web API in the same application and the  cookie that was set by forms of indication just flows back and forth now, meaning you  are implicitly authenticated in the web API as well, okay? Let me quickly show you that.  Here's a page which I have implemented, wow, the projector has a problem. So I was talking  that on that side, it's better. So you see basically what this page is doing, it iterates  over the identity, over the claims of the user and spits it out to a client browser. And  the way I do that on that page is classic MVC style, I pass in the claims as a model  into the view and I'm just rendering out the model here on the server, okay? The same thing,  the same page here, just doing the client side approach would be this, there's no model  here, yeah? And I'm actually from my page calling a web API here that returns the identity  of the user, okay? Same idea, one is server rendered, the other one is using JavaScript  to get the data while the page is being rendered on the client side. And the point being here  is both pages should return the same results because it shouldn't make a difference from  your application point of view if you're doing it server side or client side once as long  as you stay in the same domain, okay? Oops. Let's run it. So I guess I have to move that  also to the other side. Okay, can we see that? Yeah. Okay, so when I say identity server,  this is using the server rendering version, yeah? So I have to log it. And here we are,  we have two claims, my name and something I added like locally. So when I go now to  the client here, what you should see is the same thing, it's just a little bit different.  First the page renders and then the data will come because I'm doing the HX callback, okay?  So in other words, this is like the it just works scenario, okay? But there is one issue  here and that's called cross-site request forgery. When the application sends down that forms  of indication cookie, yeah, it will happily send it back every time I'm doing a request  to that same domain. That's how cookies work, yeah? But it also means, yeah, if I'm serving  to a different site, yeah, or in a different process, yeah? And this website makes a request  to my application I've been authenticated with already, the browser will send that cookie  along as well. Okay, so when I, let's do this. On this other tab, yeah, I haven't authenticated,  yeah? I'm accessing the web API directly. You see that? I'm authenticated. Okay? So  in other words, you don't want that, okay? You don't want that some application from  ChinaHackshack.com, yeah? Render some script on your browser which access another site  where you are potentially authenticated and can impersonate you, okay? So you have to  protect against that. And that is called NTCServe. Yeah? That's the problem. We go to the app,  we authenticate, we get a cookie. Now we're going to an evil app that makes requests to  the same application, we send you authentication cookie, okay? Now Microsoft has something  built in. It's not part of the framework, but it's part of the Spark template in MVC4  and it's called the validate HTTP entry for token attribute, yeah? And what this thing  is doing is basically this, yeah? So when you go to the application and it renders down  the form which has all the JavaScript on it and so on, what they do is they render two  additional things. One is a cookie which has a random or not a random number, but something  that is cryptographically derived from something on the server, okay? But it has a so-called  anti-fottery cookie that is rendered down and the form has an anti-fottery token as  a hidden field, okay? And now and whenever you are doing a post back to that page, oops,  you are basically posting back the cookie as well as the hidden field. And on the server,  what this attribute is doing, it takes the cookie value, it takes the hidden field value,  does some math on that and makes sure that they are coming from me, actually. And if  that's not the case, it will reject the request, okay? And for web API requests, what you would  send is, you would send the cookie as well and you would put that value of that hidden  field as an HTTP header on your HX call. And again, when we come back to the application,  what this attribute is doing is, it looks at the cookie, it looks at the header on your  HX call, runs some math on that if they don't match, reject the request, okay? So in other  words, the second tab doesn't know the cookie, but it doesn't know the hidden field on that  form. So it can't send both, okay? And if you want to see that in action, just go to  Visual Studio and create an empty Spark application and you will see that on the API controllers,  you will have that attribute and it's like the source code is part of the template so  you can have a look how it works and so on. But my point being here is, if you're building  that type of applications, C serve is definitely a concern, okay? So protect yourself against  that. Good. Questions on that? Okay. Now, I guess the much, much more interesting and  more common applications you will build are so-called cross-domain applications, yeah?  So even if you're, maybe your Spark application is same domain today, maybe at some point,  because of the load on it, you want to separate the front end and the back end to different  servers and then suddenly you're doing cross-domain calls, okay? And the whole cookie thing won't  work anyways, so prepare for that. But the whole idea is cross-domain applications, they  live in separate domains. One domain is here, one domain is there and that might be, you  know, a browser, that might be a native application, that might be something and you have a different  server where the web APIs live, okay? And suddenly you are in a whole new world of security scenarios.  So you have to think about authentication because cookies don't cut it anymore, yeah?  You have something called cause, which I will show you and what you ultimately want to do  is doing something called token-based authentication and the next version of web API makes that  much, much easier. Okay. So we have to authenticate our user somehow, right? And I guess the thing  that, you know, is there forever works kind of, is called shared secret authentication,  in other words, the client and the server share a secret and the client sends the secret  to the server and if that secret matches with the database, he proves that he knows that  secret. They're also called passwords, okay? That's, I guess, you know, that works. But  there are some issues with that, yeah? For example, you always have to send that credential  on the wire. Obviously, it's protected by SSL and so on, but the much bigger problem  is that the password needs to be in the memory of the client for the whole session, okay?  So you basically need to open that application, you type in your password and the client needs  to hold on to the password as long as you're talking to the server, okay? And I mean, thinking  of mobile applications, how much do users like to type in their 12 character password  every time they start the application? So what do you do then? Store it on the client  device in clear text? Because, you know, mobile devices don't have that much crypto. So yeah,  you can do it, but it's not very, you know, it's kind of old school, yeah? Slightly better  from a security point of view as so-called shared signatures, where you have like a shared  key and the client signs the HTTP request, sends the request and the server signs it  as well and makes sure that the signatures match, okay? And if you are able to sign the  request with that secret, you have proved you know the secret, yeah? And one popular  open source library for doing that is called Hock. Hock is from the guy that originally  created OAuth 2. He left the whole committee and I will talk about that in detail later  on, but one thing is what he did afterwards, he created this shared signature authentication  mechanism called Hock, yeah? I mean, you have the same problems. You have to store that  secret on the client, yeah? That might be okay for maybe company machines. That might  be not so okay for tablets or for mobile devices or whenever you generally have limited trust  in the security of the device the client is running on. Yeah. What you really want to  do, obviously because you are here in my talk, is token based authentication, yeah? And the  idea is so much better, yeah? The client has a password for example or some sort of secret.  He goes to a token service. He gives him the token service. He gets back a token in return  in exchange. The client can forget that secret from that point on, yeah? Erase memory. It's  never been seen here, okay? And from that point on, we use the token to authenticate  with the web API, okay? And the way this works on HTTP is basically you put that token on  the authorization header and a very common scheme is just saying bearer and again what  bearer exactly means come to my talk at three o'clock. Now this might be a steep curve for  some people because you need basically a separate token service infrastructure. This thing  must be highly available obviously because if this thing goes down, all web APIs go down  and sit behind it and rely on the token issuing mechanism. So what I have since I think last  year already and what web API will have in the next version is a built-in token endpoint.  Basically, we're taking this token service and moving it into the web API itself. So  when you want to get started with token-based authentication, you don't need that infrastructure  to start with but you have the same semantics. You're calling first the token service that's  built into the API, get a token, forget about the secret and use the token from that point  on. And that token could be a long list token for example saying it's valid for one week.  So users only have to type in their password once a week. Google does it every two weeks  for example. So the idea is this, you are going to a special endpoint here slash token  typically, you authenticate, you get back a token and now you use the token to authenticate.  I'll show you my implementation as I said in the next version of that API it's built  in. So let's run fitler and let's open this. And I guess again I have to move it here.  So what you're seeing here is first I'm making a round trip to the service, authenticate  and get back to this long string. That's the session token. Okay. And from that point  on I'm using session token to call the service and again what the service is doing is it's  just echoing back my identity information. Okay. So let's press F12 here. So you see  the first request, how much does that? Like this. You see the first request goes to the  token endpoint. I'm authenticating here and, hold on. Yeah. And here we get back this access  token. It's basically a JSON data structure which has two values access token and expires.  And from that point on we just use the access token. So from here on I'm making the real  calls to the business logic and you can see that we're using the session or the access  token. From that point on my client doesn't need to know the password anymore. And I don't  need to store it anymore on the client device which is I guess an important message here.  Okay. Make sense? Good. I probably don't have the time but just recently I saw a presentation  at the beach. So make sense? Okay. Okay. Now that was a C sharp client. Okay. Now let's  do exactly the same thing in JavaScript to show you another interesting problem. So let's  actually do this open the network thing here. So this is basically the moral equivalent  of the C sharp client I just wrote. Okay. It's basically something that's a credential  to the server getting back a session token and tries to use the session token afterwards.  Yeah. So let's run that. Bang. It fails. Yeah. And what it does is it sends this options  request here and this is basically a thing called course cross origin resource sharing.  So this website tries to call a web API living in a different domain and browsers don't allow  that. Okay. Otherwise you could do dangerous stuff. But given that this is kind of a popular  scenario that you actually want to do that. Yeah. There's a specification for that called  course which controls how you can do these cross origin call in the browser context.  Okay. And when we look here at the console, what it actually says is local host is not  allowed by access control. Okay. That means something has prevented to make the cross  origin call. Yeah. And the way this works is this. Basically the JavaScript living in  one domain tries to call the service in another domain. We what the browser is doing under  the covers is first sending an options request saying, Hey, I have code here that tries to  access you and it's coming from that origin and it tries to do a post. Are you cool with  that? Yeah. And now the web API needs logic saying, do I allow requests from that domain?  Yeah. And if he is cool with that, yeah, he says, okay, I allow that domain. I allow  that method. I allow these headers and it's very granular what you can do here. And then  afterwards the browser will do the actual request. If this here won't return or succeed,  the browser will just stop here. That's the error you've just seen. Okay. Now the API  version one doesn't include an implementation for course. That's again something we have  implemented and there's a message handler, the course message handler. And obviously this  is the demo mode configuration here. Yeah. All but what you can specify here things like  I allow request server one, two and three, I allow post and put and I allow the accept  content header, but not the, I don't know, whatever header. Yeah. So you can go very  granular here and you know, just by enabling that, I can read the request. And now it actually  worked. Okay. Because now there's a piece of code running in that API that understands  the options request can evaluate it against the rules engine. So to speak and then send  back the right response to that and allow that client access. So the good news here  is that Microsoft liked our implementation so much that we are now moving into system.web  with that. So basically they took our code. Yeah, thank you. Took our code and it's now  system.web.course and actually all the credits go to Brock Allen, good friend of mine who  did the actual implementation. Okay. And the way this works in the next is that you have  a new attribute called enable course. You put it on the controller, say I allow these  origins, these headers and these verbs. And that can be also stars in there if that's  too granular for you. Yeah. But that's how it will work in the next version of the API.  Okay. Move on. The next scenario that I'm seeing more and more and more in the last 12 months  going to our clients is obviously you have architectures, way model things as a web API  and you have many clients. Yeah. For example, server rendered.net clients, HTML5 JavaScript  type of clients and obviously all these native clients running on different operating systems  like desktop, mobile and so on. And obviously if your application gets that complex, then  maybe the built in token endpoint doesn't cut it anymore, right? You need more control.  You want to say like, well, this client gets access to these resources, that client gets  access to different resources. Maybe this client needs to authenticate using a web browser.  That client needs to authenticate using some different mechanism. So baking all that into  your actual web API becomes a little bit of a maintenance problem. And that's where we  factor out as always, we put a layer of abstraction in between and that's called the authorization  server and that's actually a term from OAuth 2. And the idea is that you basically take  all that logic, who is allowed to access what with which authentication method and blah,  blah, blah, blah, blah and move that to a separate server and that takes care of it.  Okay? And then basically the client goes first to the authorization server, requests the  token, gets the token, access the web API. And that is actually covered by the OAuth  2 specification, which I will talk about in detail later on, yeah? But the whole idea  is that you can come to an application architecture where you take a bunch of endpoints, a bunch  of web APIs and group them together to something called an application. Okay? That is a logical  grouping of endpoints and you define what type of resources are inside of that application.  Yeah? Maybe your application is a user management application and you say, I can delete users,  I can add users, I can, you know, add them to roles, I can search for them, blah, blah,  blah, blah. Yeah? So basically you come up with your own domain specific things of what  you can do in that application. Yeah? And now the OAuth protocol defines basically how  a client can go to the authorization server and can ask for permissions. Yeah? I want  to be able to search and read in that application. And now you can hang off rules and what you  get back is an access token. And what the access token contains is basically who is  the issuer, for which application is this token for, how long does it live, who is the  user, who is the client and what are they in combination allowed to do in the application.  Okay? That's your cost-claimed authorization and then inside your code you're doing your  fine-claimed authorization going from there. Okay? Now the issue was that there is nothing  built in or pre-built into.NET or, you know, or even products are not that common for that.  So what I've been doing the last four weeks, I've been heads down basically implementing  that stuff here. And what I want to do is I want to show it to you for the first time  in public. Yeah? So bear with me. It might break. Yeah? But the whole idea is, let's  do this, go here. You have this thing called Texture Authorization Server. And that goes  hand in hand with, you know, Identity Server. So we don't only authorization here. We don't  do authentication. Yeah? And basically what you can do is you can configure. That means  I have to authenticate with some identity provider. That could be anything. Yeah? That  could be, you know, Forms, Login, Google, Facebook, ADFS, Access Control Server, Windows,  Azure, AD, whatever you want to connect to it. And then you have now this notion of an  application. Okay? So we can create an application, give it a name, NDC, demo, give it some entry  point in the URL namespace, NDC. That's the audience claim that will go in the token.  So the recipient knows for whom this token is for. Yeah? We can give it some description.  Can have a logo. Yeah? I can set a signing key. Do I want to do symmetric signatures,  asymmetric signatures? I can specify other stuff like, do I want to require the user  to give consent when the application asks for permission, stuff like that? And then  I can save it. Okay? And now I can define scopes. So we have scopes here like your read  scope. Yeah? And what? Scopes. Read. Oh, it's required. And the delete scope, for example,  yeah? Delete. If something is really important for you, can emphasize it. So when the user  clicks the, I allow that, he sees that emphasize on the screen, yeah? Saying, hey, that's something,  you know, you should take pay attention to. And then you can per scope decide which of  your clients will be allowed to request permission for that scope. Yeah? So maybe your corporate  internet application can request delete permissions, but your iOS app can't, for example. Okay?  So basically you can hang off permissions from there. And you can also define clients.  Yeah? You can add a new client. You can tell which O of flow are they allowed to use. If  they are using something that requires, you know, a callback, you can register the redirect  you arise, you can call them back. So it allows you to pretty tightly lock down what this thing  is doing. And now let me show you how it looks like in action. So let's run an application  here called flows and O of defined so called flows that that's basically an orchestration  how clients can request tokens. And again, for the gory detail come later to my talk.  But one flow is the so called code flow. And that's for that application client. So this  is a web application. It needs to talk to a web API on behalf of the human that's sitting  in front of the browser. Okay? So what it does is basically it it goes to the authorize  server, the user signs in. And now based on the definitions you did in the UI, you get  this constant screen here saying, Hey, this client here tries to access an application  called user management and it request the read and the search permission. Do you want  to allow that? Yeah. And that screen is optional. So if you're more like an intro style of stereo,  you can turn it off that this is a silent consent if you want that. But if I press allow,  I come back to the application get a so called authorization code can exchange that code with  an access token. And now with this access token, the application can actually call the web  API. Okay? And it can store the access token. And this access token can be renewed. I think  called refresh tokens. And again, we'll talk about that in a lot of detail later on. And  at some point, the user decides he's not happy anymore that application accessing his data,  it can go to kind of a self service portal, delete the access. And the next time the application  tries to renew the token, it will fail. Okay? So that's how it looks like for web applications.  If you're doing a client application, like a native application, for example, what you  typically do is you open a web view. Yeah, so you're basically embedding a browser into  a window in your application, which opens that constant screen, the user clicks yes.  And then there's some communication going on between the web view and the client application  to send back the token. And from that point on, the client application can access the  token. Yeah. So when I do request token, I'm opening a web view here. And that's actually  quite interesting. That's a new API in Windows 8, an operating system API that gives every  application this feature of open and embedded web view. And that's kind of a special web  view here because the calling application can't intercept keystrokes and stuff like that.  And also it doesn't have access to cookies that are shared with desktop IE, for example.  So when I sign in here, I see the same constant screen. This time I only ask for read. And  by the way, I could even uncheck that here. And now the application has the token and  can access the web API. And I'm just echoing back the claims here. Okay?  For the last thing, I guess, is that you can do that all without user interaction. That  is what comes closest to W's trust if you have done that in your past. Where basically  the client itself has the credentials of the user and sends them to the authorization server  and gets back a token in response. Okay? Without all the user interaction stuff. Yeah. And  just to show you that this is actually used, yeah, so here is the Twitter application,  which is opening a web view, right? And that's the constant screen. So I'm logging in here  and say, authorize app. And from that point on, the Twitter client can access the Twitter  data on my behalf. Okay? And the other approach, the one without the user interaction in the  web view is done by Dropbox, where they collect the credentials directly, take these credentials,  go to the authorization server, get back a token in response and use the token to access  Dropbox. Okay? So that is really the pattern that you want to, that you want to prefer.  Once your application is kind of in that category where you have many web APIs, many clients,  users using different clients, maybe even throughout the day, you know, like, like maybe  at daytime, they are in the intranet and taking like a corporate, officially blessed client  application, yeah, which does all kinds of things. But on the road, they have their,  you know, their mobile device with them where you have like a company deployed mobile application,  which maybe has less access because, you know, just in case this thing gets stolen, we have  some, you know, backup plan that, you know, you can't delete everything with that, whatever,  yeah? Or maybe you have third parties building on top of open APIs that you are building,  and then you can't control them in any way. But the way you can, you know, manage all  that is by having the abstraction of an authorization server and application scopes and access tokens.  Okay? And with that, you can, you know, kind of get a better handle on these kind of complex  scenarios. Okay? So that's what I want to show you. You're seeing it here first. Actually,  you know, like in a museum when you unveil a statue, I should do one last thing. I should  do public. So here, settings, go to the scary part. And, oh, holy crap. I didn't test it,  obviously, yeah? So where's GitHub? GitHub. Yeah, here we are. It's public, okay? So if  you like that approach, thank you. If you like that approach, use it. It's in a very  stage. And by the way, I also have written a little bit of documentation already, yeah?  It's a little bit. Try it out. Give me feedback. There's an issue tracker. If you have ideas,  you know, feature ideas, problems, whatever, give us feedback. And yeah, it's now public.  We can shape this thing, okay? And I think it's tremendously useful for building these  applications. Cool. So I guess to sum it up, we went from a very simple model from, you  know, username passwords to having tokens instead, yeah? Having the authorization server  inside the actual application to factoring out to a separate authorization server, to  having a management system for these types of applications. You've seen C-Serve, which  is something you should care about. My best advice is go away from cookie-based authentication.  The next version of the Spark template in Visual Studio 2013 will be a Spark template  without cookies. It will use the exact approach I just showed you, authorization server, over  off flow, password in, token out, no cookies anymore, okay? So that's my advice. If you  go cross domain, get friendly with course, yeah? You can't escape it if you are in the  browser. And otherwise, yeah, think about your architecture in terms of access tokens.  That helped me tremendously securing them once they got more complex and so on. Any questions?  Yeah?  That's being worked on right now, but nothing official yet. I can't say it's coming, but  I think it's coming. Otherwise, it would be not too hard to write it yourself. If it's  not coming, ping me, I will write it for you, okay? Okay, then thanks for your time and see  you later, hopefully.  Thank you.
Dominick_Baier_-_Securing_ASP_0_107.png Dominick_Baier_-_Securing_ASP_108_19199.png Dominick_Baier_-_Securing_ASP_19200_19847.png Dominick_Baier_-_Securing_ASP_19848_23147.png Dominick_Baier_-_Securing_ASP_23148_24275.png Dominick_Baier_-_Securing_ASP_24276_26555.png Dominick_Baier_-_Securing_ASP_26556_29339.png Dominick_Baier_-_Securing_ASP_29340_30011.png Dominick_Baier_-_Securing_ASP_30012_30131.png Dominick_Baier_-_Securing_ASP_30132_30227.png Dominick_Baier_-_Securing_ASP_30228_31283.png Dominick_Baier_-_Securing_ASP_31284_31511.png Dominick_Baier_-_Securing_ASP_31512_31799.png Dominick_Baier_-_Securing_ASP_31800_32039.png Dominick_Baier_-_Securing_ASP_32040_35147.png Dominick_Baier_-_Securing_ASP_35148_35975.png Dominick_Baier_-_Securing_ASP_35976_36059.png Dominick_Baier_-_Securing_ASP_36060_47735.png Dominick_Baier_-_Securing_ASP_47736_47843.png Dominick_Baier_-_Securing_ASP_47844_48875.png Dominick_Baier_-_Securing_ASP_48876_49067.png Dominick_Baier_-_Securing_ASP_49068_50459.png Dominick_Baier_-_Securing_ASP_50460_51011.png Dominick_Baier_-_Securing_ASP_51012_53099.png Dominick_Baier_-_Securing_ASP_53100_53159.png Dominick_Baier_-_Securing_ASP_53160_54515.png Dominick_Baier_-_Securing_ASP_54516_56063.png Dominick_Baier_-_Securing_ASP_56064_56123.png Dominick_Baier_-_Securing_ASP_56124_61823.png Dominick_Baier_-_Securing_ASP_61824_66203.png Dominick_Baier_-_Securing_ASP_66204_66335.png Dominick_Baier_-_Securing_ASP_66336_67319.png Dominick_Baier_-_Securing_ASP_67320_68279.png Dominick_Baier_-_Securing_ASP_68280_70355.png Dominick_Baier_-_Securing_ASP_70356_70607.png Dominick_Baier_-_Securing_ASP_70608_70787.png Dominick_Baier_-_Securing_ASP_70788_71267.png Dominick_Baier_-_Securing_ASP_71268_71363.png Dominick_Baier_-_Securing_ASP_71364_71639.png Dominick_Baier_-_Securing_ASP_71640_71783.png Dominick_Baier_-_Securing_ASP_71784_71855.png Dominick_Baier_-_Securing_ASP_71856_71999.png Dominick_Baier_-_Securing_ASP_72000_72071.png Dominick_Baier_-_Securing_ASP_72072_72203.png Dominick_Baier_-_Securing_ASP_72204_73991.png Dominick_Baier_-_Securing_ASP_73992_74375.png Dominick_Baier_-_Securing_ASP_74376_75431.png Dominick_Baier_-_Securing_ASP_75432_78371.png Dominick_Baier_-_Securing_ASP_78372_78463.png