I'm having trouble getting my stateless authorization to work.
I currently have my server adding the Authorization header with the generated JWT to the HTTPResponse for the client.
My problem is the Client-side of things. I'm not quite understanding how to get the header I added on the HTTP-Response to send back in all HTTP-Requests. I've been trying to use the Bearer schema and tried without any schema but nothing seems to be working. I am not using OAuth so I'm not sure if the Bearer schema works without it. I've also tried Basic and Digest.
This is how it looks when I send it from the server.
Authorization: Bearer s5la8kdj4flak2.l4as5kdjfow2ie.owekj6nvowe4i3ej
My question is really, how do I send this Authorization header back to the server to be authenticated?
Any help would be much appreciated.
There is no way to send an Authentication header back and forth the way I was asking above. You would have to be explicitly be using Basic Authorization, which I was not.
The way I ended up doing it was making a cookie named Authorization where the body had the JWT. Cookies are automatically sent back to the server in the HTTPRequest, where I was able to strip it out in a custom filter.
Put JWT into cookie, this will protect it against theft by XSS attack
Related
I have a REST API and a frontend project like react angular. The REST API have private videos and images besides json data. So, I was using Authorization header with bearer thing. The token created via jsonwebtoken as known as jwt. So, the browser javascript does not let me to add a header while using video tag or img tag. I cannot use Authorization header anymore. I think i have two choices
I will use my token in url via queryParams, like apikey.
I will use cookie, that will automatically send cookies even using video or img tag.
So, what should i do. First option is the easiest for me, i did it before. But not much secure. Https d- oest not encrypt url. A rest api should set cookie, via using set-cookie header. Is there any problem with jwt while using cookie?
It is only safe to put a JWT into the query parameters under these conditions.
Based on what I know, using a cookie to remind your REST API that your user is authenticated would be preferable.
But do not put sensitive information in cookies, even secure and httponly cookies. From MDN Cookies:
A secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Even with Secure, sensitive information should never be stored in cookies, as they are inherently insecure and this flag can't offer real protection.
Most JWT tutorials I've seen say that you can attach it to the headers with AJAX. How do you attach the token on the initial page load?
For example, if a user goes to the base URL '/' and they don't have a token then show them the page. If they do have a token, redirect them to their profile page.
Edit:
I'm returning the generated token with a jquery ajax success function then redirecting the user. When the user gets to the home page ('/'), I'd like the access token to be sent via http headers to my server. Then the server can handle the request. However, anytime the user returns (if they close the browser and go to "mywebsite.com" or any other page), I'd like the server to be able to access the token. Are http headers the best way to do this?
success: function(token){
localStorage.setItem("token", token);
window.location.href('/');
}
If my application was a Single Page App (SPA), I could just use ajax all of the time, but it's not.
You cannot achieve what you want with HTTP headers. HTTP headers are something which are sent when a request is made to the server. In your case, you want to remember something about the client even if they close their website and come back later. The easiest to do that is through cookies.
Basically generate the JWT token for the client and send it to the client as a cookie. This logic will be written on the server side and there are many libraries available to do this depending on the technology you have chosen for server side. Then everytime the client makes a request to your server, browsers make sure that the stored cookies are sent.
I'm using a token style authentication process. After the client has obtained a token, it is either set in the client's cookies (for Web) or the authorization headers of the client's requests (for mobile). However, in order to obtain a valid token, the client must first "log in" using an valid username/password combination. My question is this:
Is there any added security by sending the username/password combination in the authorization header vs. as parameters in the JSON body of the request (assuming I'm using HTTPS)?
I only need to send the username/password combination "once" per session in order to obtain the token. Do I gain anything by doing it a la "basic-auth" style?
There's no added security in sending credentials in the Authorization header vs. a JSON body. The advantage in using the Authorization header is that you leverage on the standardized HTTP semantics, and you don't have to document exactly what clients should do. You can simply point them to the RFCs.
If you're concerned about being really RESTful, I'd say using the Authorization header instead of rolling your own method is a must.
I have a question where my client is on http://web-dev.test.com and my MVC Services are on http://webdev01.test.com . So i am trying to use ajax GET and POST json requests from my client to mvc services but it is giving me cross domain error. Can anyone explain me what the problem is? and how I could resolve this?
Thankyou
From the documentation:
Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol.
Script and JSONP requests are not subject to the same origin policy restrictions.
Making it a JSONP request, if possible, should not cause you those issues. Otherwise I'm afraid you are not going to be able to successfully complete your request.
You have two options using JSONP or CORS
For CORS you set http headers for your service so that you client will have access to it, eg
Access-Control-Allow-Origin: http://web-dev.test.com
The google drive sdk documentation in "Work with Files and Folders" section says something about the header of a post. Which is:
POST https://www.googleapis.com/drive/v2/files
Authorization: Bearer {ACCESS_TOKEN}
Content-Type: application/json
What does this mean? Does the header really exist on a jsonRequest? Where should this post go to? Should we type the header first, then, put in the json request along with the json string then post it to the server? Or does the ACCESS_TOKEN and the rest of the information be posted along with the URL as a get, like this?
POST https://www.googleapis.com/drive/v2/files?access_token={ACCESS_TOKEN}&etc=whatever&...
I understand that you need to be given an access token or an API key, but where does this go? Does this go on the url string, or does it go inside a post value or jsonRequest?
I've read the jsonRequest in json.org, but still can not get it. Do I need to consider what my content-type, content-length, and content-encoding really means? And if ever I will, where should all of these information go?
Sometimes, the answer is just staring right at my face, and before I know it, I already miss the point. So, can anybody shed me some light?
The Google Drive API is a RESTFul API using HTTP requests as the communication mechanism. The Authorization header is an HTTP header that needs to be sent along the request to authorize it. JSON is only used as the resource representation.
However, the Drive API also supports passing the OAuth 2.0 access token as a ?access_token= query parameter which can be more convenient for you.
If you are using one of supported client libraries, all this is taken care of for you through class abstractions.
The header is a standard part of an HTTP request. The standards of an http request are header fields and request methods.
POST https://www.googleapis.com/drive/v2/files
Request methods on this example is a POST and it sends the data to google drive api server. This means, the Google Drive API will accept POST requests.
Authorization: Bearer {ACCESS_TOKEN}
The Authorization, in this case, is an ACCESS_TOKEN which is the API_KEY. The server may receive also a GET request. The server checks to see if the user is authorized before it does its process: create, delete, update, or get files (depending on what the Http Request json data sends).
Content-Type: application/json
The Content-Type tells the server that the Mime Type of the HTTP request that will be sent is a json string. The Mime Type may be already a standard for the server, which means that you don’t even have to put it anywhere in your code because it assumes that you will be sending a json string, and it will receive it once you do POST. Otherwise, it will give an error. Content-Type field will always receive the Mime Type. (For a list of Mime Types, you may refer to http://en.wikipedia.org/wiki/MIME_type.)
Since HTTP Header is a standard, you will need to know what type of standards there are that Google Drive API server uses. Then, follow wherever the header fields are placed. For example, the ACCESS_TOKEN is located in the url string as a GET, and json string is located in a POST. (For a list of HTTP Header, you can also get a reference from http://en.wikipedia.org/wiki/List_of_HTTP_header_fields.)