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!
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.
I wish to implement an Auth handler for requests that handles authentication with an OAuth Authorization server to allow the following:
import requests
requests.get(url, auth=KeycloakAuth())
What I've done so far is to apply a response hook when KeycloakAuth is called, so that when the client redirects the caller to Keycloak, the hook will see the Keycloak login page, post the credentials to Keycloak and get redirected back to the client.
However, this does not work for a POST, as requests makes a POST to Keycloak's login page instead of a GET due to the redirect. Keycloak doesn't return the login form in response to a POST and this fails.
I considered checking for the redirect in the response hook so that I can modify the redirect to do a GET to Keycloak instead, but it seems like requests' implementation of redirects bypasses all the hooks.
After poking into this a bit more, I believe this may be the wrong question to ask.
I was seeking a solution where, regardless of the original HTTP method used on the client (GET, POST, HEAD, etc), the library would automatically login to Keycloak, and then "replay" the original request to the client and make it effectively transparent to the user of the library.
However, this can't possibly work with OAuth 2.0 without further state management on either the part of the library or the client, due to the redirecting.
Suppose the original request was a POST, with some data. After finding that the user is not logged in, the User-Agent will be redirected to the Authorization Server for authentication.
This means that the original request's POST data will be lost, removing the opportunity for any replay, upon the User-Agent being redirected back to the client after authentication.
With some state management, the POST data could be stored for replay - it doesn't make sense to store the data on the server side since the data could be arbitrarily large, which leaves us with the user of the library to do the state management.
However, that amount of state management should probably not belong in a library, since the library will have to handle lots of cases to guarantee only-once delivery of the request, for example, which would be expected by the user of the requests library.
As such, this Auth handler is probably not something we can implement in a library.
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
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?