Customize the Authorization HTTP header

Question

I need to authenticate a client when he sends a request to an API  The client has an API-token and I was thinking about using the standard Authorization header to send the token to the server   Normally this header is used for Basic and Digest authentication  But I don t know if I m allowed to customize the value of this header and use a custom auth-scheme  e g   Authorization  Token 1af538baa9045a84c0e889f672baf83ff24   Would you recommend this or not  Or is there an better approach to sending the token

User · Answer

I would recommend not to use HTTP authentication with custom scheme names  If you feel that you have something of generic use  you can define a new scheme  though  See http   greenbytes de tech webdav draft-ietf-httpbis-p7-auth-latest html rfc section 2 3 for details

User · Answer

Kindly try below on postman  -  In header section example work for me    Authorization    JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9 BkyB0LjKB4FIsCtnM5FcpcBLvKed j7rCCxZddwiYnU

User · Answer

This is a bit dated but there may be others looking for answers to the same question   You should think about what protection spaces make sense for your APIs   For example  you may want to identify and authenticate client application access to your APIs to restrict their use to known  registered client applications   In this case  you can use the Basic authentication scheme with the client identifier as the user-id and client shared secret as the password  You don t need proprietary authentication schemes just clearly identify the one s  to be used by clients for each protection space   I prefer only one for each protection space but the HTTP standards allow both multiple authentication schemes on each WWW-Authenticate header response and multiple WWW-Authenticate headers in each response  this will be confusing for API clients which options to use   Be consistent and clear then your APIs will be used

User · Answer

You can create your own custom auth schemas that use the Authorization  header - for example  this is how OAuth works   As a general rule  if servers or proxies don t understand the values of standard headers  they will leave them alone and ignore them  It is creating your own header keys that can often produce unexpected results - many proxies will strip headers with names they don t recognise   Having said that  it is possibly a better idea to use cookies to transmit the token  rather than the Authorization  header  for the simple reason that cookies were explicitly designed to carry custom values  whereas the specification for HTTP s built in auth methods does not really say either way - if you want to see exactly what it does say  have a look here   The other point about this is that many HTTP client libraries have built-in support for Digest and Basic auth but may make life more difficult when trying to set a raw value in the header field  whereas they will all provide easy support for cookies and will allow more or less any value within them

User · Answer

In the case of CROSS ORIGIN request read this   I faced this situation and at first I chose to use the Authorization Header and later removed it after facing the following issue   Authorization Header is considered a custom header  So if a cross-domain request is made with the Autorization Header set  the browser first sends a preflight request  A preflight request is an HTTP request by the OPTIONS method  this request strips all the parameters from the request  Your server needs to respond with Access-Control-Allow-Headers Header having the value of your custom header  Authorization header    So for each request the client  browser  sends  an additional HTTP request OPTIONS  was being sent by the browser  This deteriorated the performance of my API  You should check if adding this degrades your performance  As a workaround I am sending tokens in http parameters  which I know is not the best way of doing it but I couldn t compromise with the performance

[api] Customize the Authorization HTTP header

Examples related to api

Examples related to http

Examples related to rest

Examples related to http-headers

Examples related to authorization