![]() The server can reconstruct the digest again, since the client sends over the nonce and date. The current date and a number that we only use once (nonce) GET /users/username/account HTTP/1.1Īuthentication: hmac username:123456: ![]() We added two extra pieces of information. This is why many times more information is send over, like the current time, and a nonce: digest = base64encode(hmac("sha256", "secret", "GET+/users/username/account+20apr201312:59:24+123456")) ![]() However, the hacker could access user's account whenever it wants since it doesn't change the digest. This is why te name "secret" is preffered and not a "password".Įven if a hacker was listening in on the conversation, they could not use the authentication information to POST data to user's account details, or look at some other users accounts, or any other URL, as this would change the digest and the hacker does not have the secret that both the server and client has. Please note that the "password" is not encrypted on the server, as the server needs to know the actual value. The server can generate the digest as well, since it has all information. Right now, the server knows the user "username" tries to access the resource. This digest we can send over as a HTTP header: GET /users/username/account HTTP/1.1 Next, we generate a hmac: digest = base64encode(hmac("sha256", "secret", "GET+/users/username/account")) We could add other information as well, like the current timestamp, a random number, or the md5 of the message body in order to prevent tampering of the body, or prevent replay attacks. Here, we just concatenate the HTTP verb and the actual URL. Suppose we try to access a protected resource: /users/username/accountįirst, we need to fetch all the information we need, and concatenate this. Let's assume we have the following credentials: username "username", password "secret". Instead of having passwords that need to be sent over, we actually send a hashed version of the password, together with more information. Also, it does not safeguard against tampering of headers or body.Īnother way is to use HMAC ( hash based message authentication). One of the downsides of basic authentication is that we need to send over the password on every request. Do not use this authentication scheme on plain HTTP, but only through SSL/TLS. Note that even though your credentials are encoded, they are not encrypted! It is very easy to retrieve the username and password from a basic authentication. ![]() We use a special HTTP header where we add 'username:password' encoded in base64. The most simple way to deal with authentication is to use HTTP basic authentication. I know that it is a bit confusing that in REST APIs we are using the Authorization header for doing Authentication (or both) but if we remember that when calling an API we are requesting an access to certain resource it means that the server should know whether it should give access to that resource or not, hence when developing and designing RESTful API Authorization header sounds just fine. Authorization occurs after successful authentication.Īuthentication is stating that you are who are you are and Authorization is asking if you have access to a certain resource. This process consists of sending the credentials from the remote access client to the remote access server in an either plaintext or encrypted form by using an authentication protocol.Īuthorization is the verification that the connection attempt is allowed. The distinction between authentication and authorization is important in understanding how RESTful APIs are working and why connection attempts are either accepted or denied:Īuthentication is the verification of the credentials of the connection attempt. Wait a minute, we are talking about authentication but why the Authorization header? Authentication vs. One of the most common headers is call Authorization. Menu RESTful API Authentication Basics 28 November 2016 on REST API, Architecture, Guidelines, API, REST API SecurityĪlmost every REST API must have some sort of authentication. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |