For rest security I want to send an application key and a hash with every request. Actually I would like to have it as url parameter like
DELETE api.project.com/model/1?client=12345?hash=abcdef
Do you see any problem with this? Is there another way to send this data?
You should use Authorization HTTP header in request. If you send it as a query parameter it can be cached in many places i.e. user's browser, http caching proxy which may lead to leak of user's credentials.
On SO: Custom HTTP Authorization Header
Related
We have a third party service that implemented single-sign-on on some route to it’s web-app.
In order to use this single-sign-on, we provided with a POST API, and we need to pass on that route some credentials- including an organization secret that we got from him (yes, we need to pass it in query params), and the user’s email address.
In order to not to expose credentials over the browser, we tried to mimic that request by creating our own backend endpoint, and return the same result as their enpoint (kind of a proxy) with redirection (status 307 with Location header) cause there API returns plain HTML.
It seems like when client send a post request with redirection he can’t add the authorization header (JWT) required by our backend to operate (backend return Authorization required). the request is been done to our server and the result is redirection to another server.
How can we bypass it? Or maybe we can secure it with different approach?
I know that the header is usually been removed for a good reason, who knows where I can be redirected to?
but can't I tell him somehow that I trust the redirection?
We tried to use phantom-form only to use from submit post. We tried to make our endpoint to be GET and making the redirection other way (react-router) but I think that natively js does not allow to attach Authorization header.
I thought it would be a common pattern, but I didn't find someone that talks about it exactly, since we are trying to query our backend and not some external redirection API.
So basically I am working on an API that has authenticated routes and in order to access the route, you must pass a token and a userId. The way I currently have this implemented is the token in an Authorization header and the userId in the req body.
However, I find myself sending post requests for methods that are really meant for get requests such as fetching a user's search history but since the route is protected, I need to send the token and userId which forces me to use a post request instead.
This has made it so that all of the typical get requests are post requests. I read that post requests are slower than get requests but since the request body is so small, I don't think performance is really an issue.
But still I just want to make sure: Is it appropriate/acceptable to use post requests instead of get requests?
I know that it obviously works, but is it proper API "architecture"?
Thank you!
As the title says,I want to build a App that run in browser with a Single Html page.but how to implement the Authentication.and my solution is:
the server-side is all the RESTful APIs,which can used by multiple Platform,web ,mobile side ,etc.and every API that need auth will be get a token to parse,if the API does not get a token return 401.
cuz my first practise is in the browser,so I need to request for the token to get login,and when the app needs to request the auth-APIs,I will put the token in the header for requesting...
and my questions is : does it safe enough? any other better solution?
No it's not safe enough if the token is accessible through javascript for the same reason that you should set your cookies to http only and restrict to ssl.
If a hacker can inject javascript into your app, it can steal the token and use it from their machine.
For that reason I suggest you use a secure, http only cookie instead of the token when using a website.
If your API is going to be accessed from a native mobile app then you could add a token to each url.
Having a custom header in the http request might cause issues with certain proxies which might not pass all headers through.
A cookie is nothing more than a standardised http header so you might as well reuse that.
What you could also consider using is OAuth if you're going to allow 3rd party apps access to parts of your API.
There is no reason why you could not use cookies for browser based clients and an ApiKey query parameter for other clients.
I'm just reading Paypal's API documentation, e.g. Adaptive Accounts API
My question: What's the reason/advantage of using (custom?) HTTP Request Headers for authentication instead of "normal" POST/GET (or even COOKIE) variables?
In the mentioned example PayPal uses the following HTTP Request Headers:
X-PAYPAL-SECURITY-USERID
X-PAYPAL-SECURITY-PASSWORD
X-PAYPAL-SECURITY-SIGNATURE
X-PAYPAL-APPLICATION-ID
X-PAYPAL-DEVICE-IPADDRESS
X-PAYPAL-REQUEST-DATA-FORMAT
Why use HTTP headers rather than something in the body of the request?
By keeping your authentication info separate from the payload (the data you are transmitting) you make it easier to handle authentication at an earlier stage in the request pipeline. For example, a gatekeeper server can receive requests and authenticate them by looking only at the headers, and then pass them along to the module/server/class that does parses the request body and does the real work.
If the request fails authentication, it can be rejected before it even gets near the code that deals with the money.
Of course, you can architect your system this way no matter what, but keeping it in the headers means you don't need to parse the request body or even look at it. You also don't need to worry about adjusting Content-Length: if you wanted to modify the headers before passing it along to another server.
Why use custom HTTP headers rather than WWW-Authenticate or Cookie?
I think this is simply because PayPal wants a more robust scheme than either of these can accommodate. WWW-Authenticate only allows for basic (cleartext) and digest (MD5) authentication, and many better schemes have been developed since the spec for these was written. They also don't allow for more than a username and password.
Cookies are technically opaque bits of data that you receive from a server and pass back to it unchanged. Again, they could tell you how to generate the info that you pass along in a Cookie header, but that wouldn't really be following the spec, so at that point, why not just use some custom headers?
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication", look here.
User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.
If the connection is trusted between two parties and SSL is implemented, HTTP Authentication is a simple to implement way to authenticate between two fixed parties. The connection is simply rejected at the traffic level if the authentication fails.
I don't think Paypal uses HTTP Authentication for payments? It's just for you to access API features to build your own admin interface for Paypal accounts?
We are implementing a single sign on mechanism in an enterprise environment, where the token is shared between applications using HTTP header. Now, in order to do the integration test, I need to write an application to simulate this.
Is there any way in ASP.NET where I can redirect to another web-page and pass a custom HTTP header in the process?
Thanks
You need to create a page on Site B that Site A redirects the user too that sets a cookie with the desired value.
for instance.
http://siteb.com/authenticate.aspx?authtoken=15128901428901428904jasklads&returnUrl=http://siteb.com/index.aspx
authenticate.aspx would set a cookie and then every request would receive authtoken.
The server could send the HTTP header to the client on a redirect, but the client would not send it back to the other remote server.
The ideal solution in this case would be to use a Cookie, or a QueryString variable. Cookies may suffer from cross-domain issues and become complicated if host names are different enough.
In any of these approaches, one must be careful not to create a security hole by trusting this information as it is user input coming back from the client (or some black hat).