APIs 101: How I Secure APIs / What Does it Mean to Secure an API? Part 9

hi I'm David Berlin editor-in-chief of programmable web and I'm here to bring you the ninth part of an eleven part video series on api's 101 now in this part you can see that there's a whiteboard behind me and the reason it's here is we're going to be diagramming the workflows of a security technology called OAuth in this segment of our video series now api's 101 is for those of you who want to get smart about API it's not a deep technical dive it's basically beginner to intermediate level conversation about AP is to make you smart enough to talk to software developers and API providers and basically be able to hold any conversation about the API economy in a way that allows you to figure out what your next move is going to be so if you're expecting a real deep technical dive not here but if you're trying to get smart and bone up on what ap eyes are all about because you've been reading about them or hearing about them in the mainstream media then you've come to the right place if you have not seen the previous a part strongly suggest that you go back find those watch them first because we are building on certain bits and pieces of knowledge and detail to get to this ninth part which is the part about API security now just to review what the series is covering at the beginning we talked about what our API is and why do they matter and how do they work then we talked about why it's so important for you to invest in an api program why you should be thinking about api as a product not as a second class citizen how do you secure api that's what we're talking about in this video and then what is api first design and why is it so important that's coming up in the next segment of our series and then finally at the end get some hands-on build an api and consume it to see how the whole thing works right now just to review some basic facts that we've gone over an API is a user interface that's how we talk about it a programmable web it's just for different users now when you and I hear that term UI or user interface we often think about the menus and the screens we see when we're using our smart phones and our web browsers on our desktop computers or noble computers or tablet that's a user interface it's designed for humans to consume but an API an application programming interface it is also a user interface it's just intended for a different user not a human a machine a machine running software so that two machines can communicate with each other in the same way that you are kind of communicating with your devices when you're browsing the web or using certain applications we also talked about some great real-world metaphors that will help you better understand how api's work shipping containers Lego the wall socket in your wallet delivers 120 volts of alternating current we talked about that contract a very technical interface between the consumer and the provider of the service for example the way an electric utility provides that 120 volts of alternating current to the consumer which could be a hairdryer or maybe it's your desktop computer we talked about how that contract enables digital transformation and also creates a huge amount of flexibility in a way that organizations can drive cost out of their infrastructure create new and innovative applications move a lot faster at Lightspeed and then how all the technologies that are surrounding these api's are joining together to form what we call the API economy there's a huge proliferation of api's especially when it comes to the Internet of Things there's no such thing as a thing on the internet of things that an API is you can imagine all those devices coming online lots of api's that taking together is the API economy then we took a little bit of a tour of programmable web we showed you how we classify api's we review the different types of api's we talk about why to invest in API and then finally we went over the eight phases of the API lifecycle just like any product api's have their own life cycle it's important to know different phases and how to go through each of them and deal with the different parts and technologies that contribute to running them successfully so now we're going to talk a little bit about what it means to secure your api's now like the rest of the series this is not an advanced segment on API security this is just to give you a sense of why API security is so important so we'll cover some very basic things we'll also talk about it technology that you see being used in most API scenarios so one why is API security so important - what is the basic idea behind that security technology that was just talking about it's called OAuth what information is typically passed in an API interaction and why is constant vigilance so incredibly important when it comes to securing your API is keeping your network secure in a way that hackers don't break in and compromise something really important now one thing to consider is what are all the different parts of an API interaction that have to be secured we have the API consumer could be your smartphone could be a desktop computer could be another server another computer doesn't matter and it's going through a network it's going maybe into the cloud and doing some things up there some transformations or some workflows then it may be moving on to the actual API server itself okay all throughout that chain of events there are different opportunities to secure that transaction there's security that you can put on the API consumer the client the desktop computer the smartphone there's security you can put on the network so that the data passing through that network is encrypted and secure there's security that you can put in the cloud the security that you can put on the API endpoint at the server's location these are all very important points to think about when you're securing your API you can't just focus on one thing you have to think about it holistically and all the different parts of the transaction the difference between an API the journey from the API consumer to the API provider and how that can be secured so let's talk a little bit about some of the different areas of risk along that journey on the client end you have the app application source code that's running that application source code could be discoverable in some way by hackers one way hackers get at that source code is they find it when companies publish it by mistake on source code repositories like github another way they find that source code is they reverse engineer it when it's running on a smartphone you have to be very careful about all of the different ways that you can secure your source code and also keep any confidential information might be in the source code itself from falling into the hands of hackers shared passwords big problem out there I'm guilty I know you're guilty this is where you are using the same password maybe the same ID to log in to different services why do we do that well we subscribe to tens maybe hundreds maybe even thousands of services it's impossible for us to remember all of those passwords or a different password for every single service so very often we'll take the same password and use it across multiple services why is it a problem in the API economy because if we use an API a password to log in some service and in the same password to log into another service and a hacker discovers that password well now we've got access to two services instead of just one so this is very important to try to discourage the use of shared passwords when it comes to API interactions or to eliminate the use of passwords altogether which is what we strongly recommend and we'll show you a little bit about how to do that when it comes to our discussion of OAuth on the back end there are all kinds of security risks this is just a sampling of them sequel injection is a big problem it's one way to hackers very commonly will penetrate databases and get it sensitive data rate limiting a lot of API providers forget to put rate limits on their API what's a rate limit that's when you limit the number of times that an API consumer can come and hit your endpoint over some given period of time let's say it's somebody who has a free is using a free tier two your API many API providers have a free tier well you could give them you could put limits on how fast they can hit your API in in a way that limits their ability to try to penetrate your security and your defenses sometimes if you make it so that it's too slow they'll give up there are all sorts of reasons that rate limits are important this is just one of them one of the most common mistakes we see see when it comes to API security is how API providers overlook the implementation of rate limits improperly security endpoints is another problem now an endpoint we talked about that in the previous video part 8 an endpoint is where the the call to the API is actually made and it's no different than any other URL and in many cases these URLs are not properly secured this could be part of your overall security strategy when it comes to securing your web servers it could be part of just your API strategy depends on the organization but it's very important to secure those endpoints phishing and social social networking attacks are a big way that API hackers use to crack into an API and take advantage of any vulnerabilities they may find can't go I'm not going to go into a lot of details here but many of the different attacks that we've seen happen in a while started with a phishing attack against something somebody like a developer who is building your source code in a way that compromised the source code and led to a further compromise of the API clear text data at rest we've seen this one in the wild too we're sensitive information for example the details of an OAuth token what we're going to talk about in a minute are stored in a database in clear text that should never ever ever be the case okay and then of course on the network you have all sorts of risks to you know and what could be one potential vulnerability is that if information is being transmitted in clear text across a network and that information includes credentials then somebody could sniff the network and lift that information off and perhaps use it in a way that they can penetrate your API and cause a big problem so there are all sorts of places where you should be looking to secure the API transaction this is not an exhaustive list this is just to give you an idea that it's a jungle out there and there are plenty of places to be hunting around for hackers to break in and those same places where you should be looking to secure your API transactions now let's jump to the whiteboard and I'll show you how a typical oo auth interaction takes place and why it's so beneficial in an API interaction okay typically when you log into a service like Twitter so here's you right and here is our service Twitter will put a big t here for Twitter and when you log into that service you supply it with your ID and your password these are your credentials your user credentials okay now one thing a lot of people like to do is they like to get a third party service let's say buffer is one that such service to post to their social networks on their behalf instead of posting directly so they go through buffer and then it goes to the social network could be Twitter it could be Facebook could be LinkedIn it doesn't matter now when buffer is making a post to Twitter it is going through Twitter's API in order to do that that's how buffer makes it post to Twitter okay in the old days when you wanted a third party to post to another service on your behalf you had to give that third party your credentials not a very good practice when you think about it because then you start sprinkling your user ID and password to a whole bunch of third parties many of whom you don't have a personal relationship with so you really don't know if you're sharing with somebody that might then again share it somewhere else either on purpose or inadvertently by storing that information in a database without encrypting it first in clear-text talked about that as being one of the risks right so this is a very very vulnerable situation that somehow we have to deal with to secure the API interaction so how does Olaf do this well it's pretty straightforward it eliminates the need for you to give buffer your user ID and your password in order for buffer to post on your behalf instead what happens is they'll take out the ID and the password here for now when you tell buffer that you want to post to Twitter on you want pupper to post to Twitter on your behalf Twitter comes back to you and says hey user this third party service wants to post to us on your behalf give us your user ID and password so now you're only sharing that user ID and password with Twitter not with buffer give us a user ID and password to authorize the third party to post on your behalf so they ask you that question and you send that data back and then once you've authorized that transaction Twitter will go ahead and give buffer something called a token now it's a little more complicated than that there are a couple different tokens that get transmitted but that token put a little token here T okay that token is now a basic representation of your user ID and password it's not your actual user ID and password so that token is only good so that buffer can act on your behalf and post to Twitter anytime buffer wants to make a post through the API it sends that token along the way to the API when the API sees a token it says AHA that's this user using buffer to access Twitter now why is this such a great scheme well one reason is that the token is specific to this user and to this application again the token has been issued by Twitter so if at any point in time Twitter wants to revoke that access they can just knock out this one token and now buffer can no longer act on the user's behalf in terms of making a post to Twitter another thing that's great about this scheme is that if Twitter decides that buffer is has got a security problem and they need to take away all of the users who are using buffers their access to Twitter through that path they can say all right let's look for all the tokens that we issued to buffer and revoke them as well and that will secure Twitter's API from a bad actor like buffer if buffer was a bad actor point got to point out one thing here buffer is a great actor okay so I don't want to me I don't want to sue my mat I'm just making an example here so let's be clear I'm not trying to throw anybody onto the bus right buffers are really good actor when it comes to dealing with making social posts but is an example of why the token scheme is so useful when it comes to API security right and you see this happening all the time now in most in most API interactions particularly where one service is acting on behalf of the user making a post to a third-party service so there's our whiteboard now let's review how off helps to keep credentials secure number one in the early days of basically what we call basic authentication a lot of times you would pass a user ID and a password in any sort of transaction this is not a great idea in this day and age of the network where a lot of that information is discoverable right so we want to make sure we're not sharing that data with third parties in a way that we're sprinkling what is otherwise confidential information all over the network to people we don't need to know and should necessarily trust ok also we need some security that makes it difficult for hackers it should they get into the databases where this information is stored to wreak havoc at scale one of the big issues here is is like if a hacker comes across one token they can't do a whole lot of damage and by the way just the same way that Twitter could revoke a token because they detected some sort of security problem you can also go in and revoke the token that you issued to buffer so it gives the end-user some control over their API interactions as well the open authentication protocol o auth was introduced as a token based authentication system it definitely prevents the API client in this case let's say it's buffer or could be a mobile application that is accessing a network on a service on your behalf the token prevents that app that your user ID and your credentials from being stored in that application so it doesn't matter if it's a network service like buffer or if it's a mobile application on your phone you don't want that mobile application basically caching your user ID and password you only want it to have this token that represents your Jules okay so what are the benefits here the loan token if anybody gets ahold of it is useless it's like finding a key in the middle of the road okay the token is also specific as I mentioned earlier to the intersection of a user and a specific application so if a hacker comes across that one token they can't do a whole lot of damage the same way they could if they for example we're able to run a query of a database and discover a whole bunch of user IDs and passwords it provides a layer of accountability on the on the API provider side because they can monitor usage of their API on a token by token basis this is very important we talked a little bit about measurability and being able to set up dashboards and things like that the token becomes like one of the central core pieces of your governance policy again I said you can revoke tokens you can revoke the access for an entire application for all of the users using that application or just one user so this is very important in the overall scheme of securing your API can be deleted at any time it doesn't matter whether it's misuse security breach or at the end users choice and one other important point that I failed to mention earlier is that these tokens over here can expire you can set a time so that they're only good for a certain period of time hours days maybe weeks or months however it is however important you think it is to expire tokens let's say a hacker gets ahold of a token and can somehow compromise your API once they've got a hold of that token we've seen that happen in the wild so it does happen but if that token has an expiration time associated with it by the time the hacker gets around to trying to penetrate your network if the token is expired something that user IDs and passwords don't do and let's the end user changes them well if the token is expired then it's no good anymore they can't use it to try to wreak havoc on your API so making sure you take advantage of the option to expire tokens is a very important technique in securing your API so now I want to show you a typical interaction in real and in the real world of how ooofff works and how it looks to the end-user okay so here we are on one of my Twitter accounts it's one that I have not used it a long time so we'll use it for demonstration purposes to show how Twitter will authorize a buffer to post on my behalf using an auth token so you get to see the end-user experience of how that happens here so we're on my Twitter page right now and if we go to the buffer service to buffer comm and we try to connect my Twitter account to it you're going to see an authorization dialogue come up now what's important here is is that it's going to ask my user ID and password but that authorization dialogue isn't coming from buffer it's going to come from Twitter so let's see what happens there you go now Twitter is saying should it authorized buffer to use my account and if you look up here in the URL you'll see that it's a URL whose base is API Twitter comm this is a an integral part of Twitter's API security it's asking me if I approve buffer to be posting to Twitter on my behalf and in order to do that I have to supply my password now the good news here is I'm only supplying the password to Twitter not to buffer so let's put that in and i'm the author izing the app and now it's redirecting me back to buffer and here now I can make a post to Twitter a using buffer without me having to log directly in to Twitter buffer now has a token that represents me and buffer that intersection of me any application in a way that it will authenticate against Twitter network and allowing me make that post that gives you some idea of how that works now if for some reason Twitter decided that they needed to revoke the applications token in order to prevent some sort of security infiltration they could just take away that token and another thing that's really important here is I can always go back to my Twitter account and I can pull up my profile I can go into the account settings which are here I can go scroll down to the application tab and I can revoke the token myself so the end-user has a lot of control here I can just click the revoke and there it is now that token will no longer be able to ignore use that token to post a Twitter on my behalf as though the post was coming from buffer so that gives you some idea of the end-user experience when it comes to OAuth tokens and how they can add and strengthen your API security okay so now you have a good idea of what it looks like from the end-user perspective when Ola tokens are being used to secure their interactions with a service through an API when you're using a third-party application I know that was a mouthful there but it's really not so intimidating and it's actually a very good thing to do your users will feel more comfortable knowing that they're not passing the credentials to some third party who they don't know or don't shouldn't be trusting now when a typical API interaction takes place it is useful to know what some of the information is it's being transferred back and forth depending on the implementation so user ID and password are sometimes passed back and forth in an API interaction that is when the API provider is depending on what we call basic authentication again that's something that we strongly recommend against doing but it is still being done with many api's and those two bits of information are in fact secret right you shouldn't be sharing those also there's something called the API key when a developer registers to use your API you very often will issue them what's called an API key it's like a key that's unique to that developer so that from that point forward whenever that developer is accessing your network then you can use the key to uniquely identify them associate traffic with them or maybe check on whether or not they're trying to exceed their the limits of the tier that they're participating in that's the unique identifier that added that identifies each developer it should not be treated as a security mechanism a lot of people think because it's using the word key that it's one way of securing an API well to be honest with you it's not it really doesn't help them securing the API it really more helps with your ability to measure what's going on with certain developers there's also an application secret that gets transferred back and forth in many of your API interactions and unfortunately even though that was used as a security mechanism it's not really helping that much these days it's almost like the key typically speaking the application secret is now discoverable by hackers and so make sure that when you are deploying your API s and allowing developers to access them that you don't depend on things like the API key an application secret alone to secure your API of course the OAuth request token we just talked about that on the whiteboard behind me and that is a key to improving your security over these other forms that some API providers are using to authenticate API interactions and the bearer token the request token is basically the token that's used to request the bearer token so there are a couple different bits and pieces of what we call the OAuth workflow that I didn't expose in my very simple diagram here but you should know that there's a token for requesting the access token and then once you're authorized to have that access token then the third-party application should be able to access the service on your beyond the end-users behalf now earlier I mentioned something about constant vigilance you can't just look at this once and say ok we're done we did a whole bunch of things and the reason is it's sort of a moving target API security as it turns out is very very difficult and just to give you an idea of how hard it is here's a list a short list of five companies five very well-known internet companies very well-funded able to afford the very best talent out there and all of them have had API security problems right and if those problems have been publicized we've written about it on programmable web so Google problem Facebook Apple Twitter Pinterest they've all had problems with their API security so you have to keep in the back of your mind boy if it's challenging for them it's going to be double challenging for me and we have to be vigilant about keeping hackers out of our networks okay ooofff right now is pretty much the only thing that prevents hackers from getting free access to accounts when we're talking about an API interaction there are some other ways but they are sort of home-cooked and I would strongly advise most of you not to try to bake your own security that way o auth is a standard and the most the easiest and most standard way of putting security in place without requiring user IDs and passwords be transferred between a third party application and your API so strongly recommend that you put that in place so that none of your developers can compromise your security always take a security for first approach when using OAuth take advantage of some of the some of the built-in functionality of all off for example the ability to expire tokens but also make sure that when you put those tokens in a database because you will undoubtedly have to do that or when they're being stored in a database tell you those third party application providers to make sure that they are stored in an encrypted form okay we have seen several major hacks of API providers and one of the reasons that those hacks were successful is because the third-party applications that took delivery of those Olof tokens stored those tokens and clear text make sure that you're telling any developer that those tokens have to be encrypted and before doing anything do a much deeper dive on all of the security technologies that are related to API is particularly OAuth is a moving target there are standards bodies at the IETF that are working night and day on improving all of the different underpinnings to OAuth and its behold it upon you as an API provider to make sure that you are staying on top of the changes that are being made to the standard so that you can have the most recent and up-to-date technologies in your API stack in such a way that it guarantees theory of your api's the reason they're doing that is because the existing API stack has been proven to have a new vulnerability that they didn't see before so they're constantly battening down the hatches it's very important that every time they batten down a new hatch you incorporate that new technology into your stack so that you are fully secure now we deal with a lot of people who have a lot of different sources that we go to when we're writing new stories and programmable web and I think this is one of the most important points this is one of our sources who works at a security company that everybody knows said to me if he were advising a nation-state on how to bring down the United States of America he would tell them to go after the api's first that it gives you some idea of where hackers might focus their emphasis when they want to do damage imagine if some other nation-state decided to attack all of the the big companies that have api's in the internet like Google and Amazon and the government the government facilities that are using api's all of that infrastructure if it were somehow brought down could really bring down a nation-state pretty quickly so this gives you some idea of how imperative it is to keep your API secure so thanks very much I hope you enjoyed this part of our series next we're going to talk about API first design in our tenth part of the video series we'll see you there you

Channel: ProgrammableWeb

Views: 59,697

Keywords: API, APIs, Application Development, Coding, Programming, Developers, Development, Application Programming Interface, SDK

Id: rAElZVyVEa4

Length: 30min 23sec (1823 seconds)

Published: Fri Jul 07 2017