Advanced JAX-RS 22 - REST API Authentication Mechanisms

all right so this lesson is going to be some introduction to how you would do authentication in your REST API s I'm going to talk about some of the challenges we have with authentication specifically for REST API and some of the ways we can get around those challenges and I'm going to highlight the basic card scenario that we are actually going to implement in the next tutorial all right so before we get into SDP authentication itself let's talk about how the classic session based authentication works right assume Anand REST API application a classic servers deployed web application how would a client establish a session how would a client do a login and authenticate well what would typically happen is when the client makes a call to the server the first thing the client does is authenticate right it passes in the username and the password it says hey server this is who I am and this is the password to prove it right now once this call is made the server validates this username and password if it finds that the values are right what it does is it makes a record of it right it says okay this is a client who has passed my check now I'm going to save this information in a session object right in the session the server maintains this information about the fact that the client sent the username and password and they registered and they can be trusted so what the server does is it makes it creates this object in the memory called the session and the session probably has some kind of an ID some kind of a token now the server in its response to the client sends back that session token now the client needs to hold on to the session token and the next time the client talks to the server it needs to send this token back it needs to say hey server remember you had authenticated me some time back and I have a session token to prove that I am indeed that person so the session token needs to be sent back so what servers typically do is it sends the token back as a cookie so the client has that value in the cookie so the next time the client makes a call to the server that value the session token' gets sent to the server through the cookie and the server says okay I know the session token' I have the session value over here so I know who you are the next time decline needs to make a call it sends the session token again and so on and when the client is finally done it says hey server I want to log off and the server destroys the session so this is classic session based authentication I'm sure you're familiar with this this is all over the place there are a lot of websites which do session based authentication like this well this is nice and simple this is going to be a problem for REST API is because REST API is are stateless at least they're supposed to be stateless now what do I mean by stateless stateless essentially means that the server the obligation running on the server does not maintain any state does not maintain information that persists across multiple requests ideally when a client makes a request to a REST API the REST API application does what it needs to do to serve that request it does all the processing this required prepares the response and sense that response to the client and then completely forgets about it there is no state that's maintained there's no information that's persisted ok this is what REST API should be right it should not remember a previous interaction between the client and the server well if this is to be true then we have a problem session based authentication does not work anymore because you cannot have this guy you cannot have the session this goes away now the client cannot vanish is this kind of an interaction right so the client has a session token' within the next time the client sends the session token' their services ok I have no idea who you are I have no memory of you ok this is a problem with REST API ice so there are a few ways to solve this problem there are actually a lot of ways to solve this there have been a bunch of different authentication mechanisms that are stateless and that you can use for rest api s i'm going to give you a list of some of these authentication mechanisms and i'm going to talk in detail about the most basic of them which is basic auth it's also called basic access authentication this is how it works with basic auth the first time the client needs to make a call to the server and it needs to authenticate it sends the username and password the second time the client needs to make a call to the server it sends the username and password again the third time it sends the username and password so there is no state being maintained on the server which is fine because the client happens to authenticate for every single request every time the client talks to the server it is sending the username and password information well they weren't kidding when they call this basic auth well this is the most basic of authentication mechanisms there are some nuances about how this username and password is being sent to the server though and I'm going to cover that next the V the username and password is sent to the server in every request is in the header of that request now let's say this is your request in your header you want to save your username and password this is done in a specific way in basic auth but the idea is the same so you send the request which is what you want which is what you would typically send without any authentication but in the request header you pass in the username and the password in order to authenticate yourself to the server the thing though is you don't just add the username and password as this there is a specific protocol to this there's a specific way in which you got to do this so the way to do this is you take the username and the password and you add them a both separated by the : symbol all right so it's username : password so now we have a string you take that and you do base64 encoding so you encode that username : password string and basics t4 and you get an encoded string okay you take this end coded string and in your request in your header you create a new header key called authorization and now the value of this authorization is the string basic but B caps and separated by a space you add this encoded string alright so these are the steps to send username and password in the request from the client ok so again to summarize we have user name colon password write user name string colon password string you take that combined string value and you do base64 encoding and you get an encoded string now you send that encoded string in the header of your request you say authorization or just the header name and the value is basic and the encoded string okay now how does this work on the server side the server side it's the exact opposite now the server gets this request and it examines the authorization header it gets the value right it checks the first word it says basic so it knows it's basic authentication now it gets the second word which is the encoded string now it's going to do base64 decoding to get username : password so it's going to take the string before the colon character and take that as username it's going to take the string after the colon character and it's going to take that as a password and it checks if the username and password match okay now I want to mention something about base64 encoding and decoding that we do over here you should remember that this is not encryption okay this is not a secret encoding is just a way for you to convert a string to another string or something that anybody can do so this string this encoded string is not secur anybody who has access to this encoded string can always decode okay so even though you encode your user name and password in the header it is available for anybody to decode so you always have to make sure when you send username and password in a request header in this basic auth scenario you always send this request over HTTPS so that the request is protected people cannot look at the header and examine the value because if somebody sees this base64 encoded string it's child's play to get the username and password out of it right anybody can do basics for decoding and get the actual values so you always have to send a request with this encoded string in the header you always send it over HTTPS but now the question is if anybody can access this by encode why not just send the username colon password as the string the reason we encode it is so that we encode non-http compatible characters it's not for security we don't want to hide this of course I can look at the string and I don't know what the username and password is but it's one step away from getting the username and password it's not to hide it it's not to make it secure the reason we encode it is so that if there are non HTTP compatible characters in either the username or the password we encoded so that we make sure that the string is HTTP compatible so this is a snippet from an earlier version of the Wikipedia page on basic access authentication I don't know why it's removed from the current version so I have this link here which goes to the old version which has this paragraph I think this is pretty useful it's a security is not the intent of the encoding step rather the intent of the encoding is to encode non-http compatible characters that may be used in the user name or password into those that are HTTP compatible that's the whole point of the encoding right if you if you set that aside you're basically sending the username and the password in the request header it's as simple as that all right so this is basic God in a nutshell right the client sends the username and the password in the request every time all the whole encoding thing and putting it in my header those are details but the idea is the credentials are send for every request in the header now let's talk about some of the advantages and disadvantages of this approach well the biggest advantage is it's simple I can cover this in one lesson in a tutorial video which is why I happen to pick this but this is actually pretty handy when you are just getting into authentication you want to learn the most basic stuff before you move on to some advanced stuff the second advantage is you have a stateless server which was the goal all along right the server doesn't maintain state the server doesn't hold on to a session because this information is being sent every time the third advantage is this is just a header value right this is supported by all browsers so you don't have to worry about some proprietary authentication you know process that only certain browser support this is a header value it's basic stuff all browser supported now what are the disadvantages the biggest disadvantage it's the username and the password out in the open even though it's encoded it's for everybody to see so you have to send this over HTTP in order to have at least some kind of protection the other disadvantage is it is subject to replay attacks what a replay attack means is somebody gets hold off a request they can resend the request as many times as they want and since the username and the password is being sent every time that request goes through all right the server is bound to authenticate that successfully so anybody can get hold of this request especially if it's not over HTTPS and make the request on behalf of a valid user and take over the account or some dire consequence like that now the third disadvantage is logout is tricky imagine how you would do a logout functionality logout usually works in a class scenario where a session is maintained a logout kills that session right the session no longer is available on the server but if every request sends this value and let's say the browser is cashing that logging out as tricky all right so this is a the basic cut and some advantages and disadvantages now what are some other approaches we can take there are some better solutions there is this other authentication called digest access authentication this actually does encryption off a secret key that's being sent in the header the basic cart just sends to username in the password without any encryption the digest access authentication does some kind of encryption it doesn't have username and password though it has something called a secret I have this Wikipedia link where you can read more about digest access authentication the other solution is asymmetric cryptography this is the public key cryptography so there's a public key and a private key that both the client and the server both have and they share a public key while they have their own individual private keys and that's what they used to encrypt and decrypt the credentials that get sent over in the request again I have a Wikipedia link if you're curious the other solution is something called OAuth this is actually gaining in popularity there are actually two versions there's what one and what two while they have the same name they are actually not the same protocol they're actually very different what two has very little resemblance to one but that's something you know this is a protocol that's been gaining a lot of popularity again I have the Wikipedia link if you're interested another growing trend in REST API authentication implementation is JSON web tokens and this is again a Wikipedia link so all these authentication mechanisms provide a way for you to send credential information without having to maintain state on the server which is perfect for rest api s-- so hopefully this gives you a quick primer a quick introduction to authentication in restful api s I obviously cannot cover all of these mechanisms because that's a course in itself I'm going to talk about the basic auth the scenario that we just discussed where the client sends the username and the password but it is base64 encoded we can implement that using filters in Jack's iris

Channel: Java Brains

Views: 131,896

Keywords: java brains, java, brains, koushik kothagal, koushik, kothagal, kaushik, JAX-RS, REST, RESTful, Web services, Jersey, Java EE, Tomcat, Apache, Java API For RESTful Web Services, Representational State Transfer (Internet Protocol)

Id: 501dpx2IjGY

Length: 15min 58sec (958 seconds)

Published: Tue Jan 26 2016