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.
Related
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.
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
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 am new to API development. Currently I pass my access/auth token in request body. For eaxmple,
{
status:true,
token:"<thetoken>"
}
But, When I refer about API security, They use Authorization header to pass the token.
My question is, What will happen or Whats wrong, If I send token in request body?
-- Thank you ❤ ---
First of all, securing API endpoints is a solved task. Instead of inventing your own authorization protocol, I suggest you to have a look at already existing industry standards like the OAuth 2.0 Authorization Framework (RFC 6749).
Following standards makes sense for multiple reasons:
they are widely known and battle tested
reference implementations and libs are available
you can stand on the shoulders of giants and focus on your business logic
etc.
However, there is nothing wrong with sending an access token in a request body. In RFC 6750 the OAuth 2.0 protocol defines all possible bearer token usages including sending the token as a Form-Encoded Body Parameter. Make sure to read carefully and take the security considerations into account.
Long story short: It does not really matter how you hand around access token, as long as you follow the standards.
I know there is enough content for this question on the Stack Overflow but my subject is not the same as the others. ( Kinda the same but not equal )
I want to hear the community thoughts of what I doing and to see if I can improve somewhere or not.
I'm currently using BASIC Authorization for my login EndPoint as it doesn't require complexity and its over https so its fine the way it is.
Example:
GET - /api/login
Authorization : Basic BASE64String(username:password)
Some of my EndPoints require Tokens to be granted access to the resource. These Tokens I'm sending trough Headers and Https-Secured.
The thing is I'm not using a conventional method of doing these Authorizations. Some examples below:
Example 1:
GET - /api/hardware/{PUBLIC_TOKEN}/getMe
Authorization-Hardware : PRIVATE_TOKEN
This EndPoint doesn't require the Authorization-Hardware Header, but if included more things are done by the API. ( Not relevant here )
Example 2:
GET - /api/login/{id}
Authorization-Person : USER_TOKEN
This EndPoint otherwise is necessary including the Authorization-Person Header with the User Token to access the resource. ( Note that how the Token is generated is irrelevant here )
To access the API EndPoints an HTTPS request is necessary.
I gave arbitrary names to the Custom Headers and EndPoints above just to give a picture of what my Authorization Schema is, the names doesn't match the original ones. So don't bother the names just foccus on the schema.
My question is: Not following the convetional way is such a bad thing ? Creating Custom Authorization Headers is bad somehow ( if it is why ? ).
I find this way simpler to give Authorization and a secure way of passing tokens, all these Tokens can be re-generated in the platform again.
Lots of devices and a Mobile Application is already using this Schema, but its all under Development Environment and its not in Production yet. My fear is that this non-conventional way of doing this can affect users of the API in the future. Hope the community thoughts can help me to improve this.
EDIT: 26/03/2017
I would like to know if it would be better and why implementing in the way that is described in the protocol, as its harder to fetch from the Headers when multiple Authorizations is required than when you have a Custom Header and wants to retrieve its value.
Following the Protocol you should use Authorization Header like this:
Authorization: <type> <value>
Example:
GET - /api/login/{id}
Authorization : User USER_TOKEN
But I just can't see what I gain following this, because when fetching its value would come a String or in the example case it would return User Token.
Using an Custom Header its way easier validating the Token. Multiple Authorizations can give a headache too following the protocol way.
TL;DR Some header names such as Authorization have special rules about caching as well as proxy & client handling; your custom header names would not get the special behavior unless you modified every single proxy & client.
The point of using the common Authorization: <type> <value> header as defined in RFC7234 is mostly to ensure that clients & HTTP proxies that natively implement handling of those headers behave CORRECTLY.
Section 4.2 of RFC7234 says:
A proxy forwarding a request MUST NOT modify any Authorization fields
in that request. See Section 3.2 of [RFC7234] for details of and
requirements pertaining to handling of the Authorization field by
HTTP caches.
The Proxy may modify, omit, log or cache your other Authorization-* headers.
RFC7234, section 3.2 says that requests/responses Authorization header MUST not be cached (except in specific circumstances).
RFC7235, section 5.1.2, point 7 furthermore has this say to about NEW authentication schemes that use headers other than Authorization:
Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response directives (e.g., "private").
So what should you do...? If you controller both ends of the system entirely, it's not unreasonable to define a new type value that might have multiple parameters to cover any combination of one or more token types, just avoiding the , character:
Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...
The alternative depends on server & client implementations more, and would be using a , as the alternate version list form of multiple headers:
Authorization: User USER_TOKEN, Hardware=HWTOKEN, Person=PERSONTOKEN, Basic=...
Which depending on the server & client, may be treated the same as:
Authorization: User USER_TOKEN
Authorization: Hardware HWTOKEN
Authorization: Person PERSONTOKEN
Authorization: Basic ...
The problem here is "MAY" (lots of added emphasis) be treated the same. There's discussions suggestion that various versions of Apache & NGINX don't treat this consistently, and that the older HTTP RFCs are very unclear about the intended behavior.