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
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.
I'm kind of surprised that, after searching for this for a while, I didn't find as many answers as I thought would be out there (well I found none), so maybe by asking it here we can help improve search results.
I'm building a REST api which has JWT-based authentication. There is an /auth/login route which returns the token after login/password verification, and the token is subsequently sent in every route in a Authorization http header.
Not, suppose that someone queries another route (say, /cars), without sending the token (that is, before logging in). If I return a 401 unauthorized, I can make the frontend query /auth/login to get the token.
But, strictly speaking, this does not conform to the REST specification, because every resource should be discoverable from the initial one, and a client accessing /cars and receiving a 401 will not know about /auth/login.
So another option would be a redirection like 302. But this semantics means that the resource was temporarily moved, and this is not the case (the resource is still /cars, you just need to authenticate first).
So, what is the correct way to do this procedure in a "true" rest api?
I 100% agree, and that's why I proposed this standard:
https://datatracker.ietf.org/doc/html/draft-pot-authentication-link-01
The idea is that for cases like this, you should be able to return a Link header with an authentication rel, so the client can discover how to proceed.
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
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.
The logic looks circular to me(although I know I'm missing something)
I want to use this:
https://dev.twitter.com/docs/auth/pin-based-authorization
But in order to make the url to send the user to get the pin you need an "oauth_token" :
https://dev.twitter.com/docs/api/1/get/oauth/authorize
But to get the "oauth_token" you need a:
https://dev.twitter.com/docs/api/1/post/oauth/request_token
But that at the bottom shows it needs an "oauth_signature"
Well, an "oauth_signature" requires an "oauth_token"
( https://dev.twitter.com/docs/auth/creating-signature ) which you don't have, making impossible to get an "oauth_token" because you need one to get one.
What am I missing here? I mainly just want to find out how to get that initial url for the PIN-based authorization, so I need that first "oauth_token" somehow.
There are two different types of oauth tokens - let's call them request tokens and normal tokens. Request tokens are used for the authentication, then once the authentication is done you get normal oauth tokens.
Calling oauth/request_token will generate a request token for you, which is a temporary token used for the actual authentication. Once that's done you have the normal tokens.
set the callback URL both https://apps.twitter.com/ and in your code
. It is working for Me.
oauthCallback:#"myapp://twitter_access_tokens/"