Which is the right approach to send user credentials from the front end to the backend server?
I see examples where some developers use the authorization headers and some pass the credentials in the POST body.
Credentials usually go to the request body once, when trying log in.
You should receive a token in return, although whether you send this token via HTTP header, request body or as a GET param is up to you ( or the protocol you are implementing ).
It's generally a good practice to use the header, because GET requests shouldn't include request body and passing the token as a GET parameter may not always be an option ( e.g. due to the token appearing in various logs ).
Either way, I would advise you to avoid trying to implement your own protocol and use an existing standard instead.
The only safe method for a website to transfer a password to the server is using HTTPS/SSL. If the connection itself is not encrypted, a ManInTheMiddle can modify or strip away any JavaScript sent to the client. So you cannot rely on client-side hashing.
Moreover always use headers for sending sensitive data like USER-ID, API-KEY, AUTH-TOKENS
You can refer to this stack question also link for more information and this link
Related
I have read about the relayState parameter in SAML SSO, and how the SP can redirect the user back to the original incoming URL by making use of relayState, but to my knowledge HTTP redirect only works for GET requests.
I am wondering if the same can be done for POST, PUT and DELETE requests, considering these requests usually come with data in the request body as well. I thought of returning a self-submitting form for POST requests, but this won't work for any other HTTP verb, and the original request must be a form based request too, unless the framework supports treating all types of parameters (query string, form field, json element) similarly. I also thought of making the frontend reconstruct the original request and sending it back to SP with AJAX, but I'm not sure if AJAX can actually update the browser's current page address.
My compromise solution in the end was to only relay URLs that result in a whole new page rendering with a GET verb only, and for any other requests, use the referrer URL for relaying instead. This means for the latter, the user will have to perform the task manually again after landing on the page he last saw before the SSO flow.
Not sure what the common practice in the industry is.
Thank you!
you would to maintain / save the POST data on the SP end and re-use them after SAML flow succeed. SAML as such does not provide any mean to achieve this.
Steps:
Hitting the website- It is being redirected to an URL which contains parameters such as STATE, NONCE and CLIENT-REQUEST-ID which are dynamic.
So, in JMeter, I am unable to fetch those values as those are coming directly in a HTTP request.
Any Idea, how to fetch it?
While clicking on sign in with credentials, authentication process is happening which is generating a token id.
Then in next request, redirects occur and same kind of URL is achieved (as in step1). Again same parameters are passed.
And with this request, Access token is generated.
I am unable to fetch those parameter (nonce, state, client request id). Is there anything we can do?
According to Microsoft, client-request-id is optional (so you can probably just leave it off) and if I read this right is generated by the client. So you may be able to just generate a random GUID in JMeter.
If you're being redirected to an URL which contains the parameters you're looking for you should be able to capture them from the sub-sampler
using a suitable Post-Processor like Regular Expression Extractor
Also some values like consumer key are static and never change and some values like nonce are random
If you don't need to load test the OAuth login challenge itself you can ask developers or administrators to provide you a permanent token which you can send in the Authorization header using HTTP Header Manager
Yes, you are correct but in my case I am not getting any sub-sampler(s).
That's where trouble lies!
Also, those parameters are coming from 3rd Party which is hosting the site(not in the hands of Devs)..
The whole process I am doing is for load testing.
So, any thing you wanna add for this?
Why do we prefer to send User credentials and JWT token in headers?
I am working on a proejct where i have to send user crednetials in header. But i don't understand why can't we use request json (payload) instead of header?
Various reasons. For one it is simply better to evaluate the request header before even considering the body. Think of it this way - if you send a letter to another person, the person will only get the letter if the letter is correctly addressed to him. If he required a verification of the sender (analogy of using tokens in requests) and it isn't there - we shouldn't open the letter.
Another reason is that for example get requests doesn't have a body. So you want to have the token placement streamlined for all requests types.
It is safe to include the token in the header as long as you use https, see this question
My app API requires authentication via an authentication token. In short, we send a request to a /authentication endpoint and it responds with a JSON object containing a token, like:
{"token": "xxxxxxxxxxxxxxxxxxxxxx"}
Every other API endpoint in our application requires an authentication header containing this token. Now, in Postman it's possible to do the authentication request, copy the token, open the next endpoint and paste the authentication header in manually. But this becomes tedious and time-consuming when testing lots of endpoints.
Is there a way to have Postman save and automatically add the authentication token from one request in any follow-up requests?
Even better, could Postman automatically send the /authentication request prior to any of the other requests?
Postman allows you a wide variety of options when crafting API requests.
In your case, You can create a global variable for your token when you receive it by:
var jsonData = JSON.parse(responseBody);
postman.setGlobalVariable('token', jsonData.token);
This would go in your Tests tab, in order to execute this script after your request has been completed.
Now, a global variable token is set and can be accessed using {{token}} syntax in the following API requests you make.
I'll demonstrate it to you regarding the same, with a similar example:
1. Save the data of latitude and longitude into the global variables lat and long.
2. Reuse the data by referring to the name of the variable, i.e. lat and long by enclosing them within curly braces like {{lat}} and {{long}}.
You can also manage these global variables, by clicking on the gear icon in the top right corner, and selecting manage environments then opening the Globals tab.
Tip: You can also, save the request to obtain the token into your collections, so that each time, you don't have to craft the URL to obtain the token.
I found a doubt when I was designing API. Some documents guide developers how to make and deal with token.
If I will access a website requiring token authentication, I should set my token in HTTP header, let service ascertain my validity.
Although I think designing setting up method can be flexible, for examples, setting in header or body, I don't know what difference are they?
In this token case, because token is secret info, is setting in header safer than in body? or setting in header can't make HTTP be a burden? What information does it fit with setting in header?
It's no special when data sets in header or body.
Except you have specail data needs to set in header, and then your web application only accepts the specify method to do. It follows you how to desgin the processing workflow.