I have a Django Rest Framework api that uses bearer token for authentication behind Nginx reverse proxy. I'm setting up basic authentication to protect the proxy in the development server, but I'm not sure what's the best way to protect the api using both authentication methods. I need two authentication methods, because I'd like only admins to be able to see the api page (even if the private information were only accessible to people with the bearer token). I have read that using multiple values in the Authorization header is not compatible with the spec, so I was thinking that maybe I could switch the header used by Django from Authorization to "Custom-Authorization", but the solution seems hack-ish. I'd rather have an Nginx solution for this (and even use custom header for basic auth if that were possible). What would you recommend?
You find the answer here: Multiple HTTP Authorization headers?
=> basic authentication and bearer token are sharing the same header. This is basically the reason why it is not working.
Related
I'm writing an application that use woocommerce REST API with Basic authentication. In each request I should add a username and password in base64 encoding. However, each authentication header can i preview in the browser, decode and execute requests from another place which I would not like, of course.
Did I configure apps incorrectly?
I do not understand how it would be safe, since everyone can get the keys from the header.
How to configure this connection correctly?
Maybe should I use JWT auth?
woocommerce-rest-api IS NOT frondend rest api. To be able to use this on the front should be properly adapted ACL. This help me understand
I am successfully using bearer token authentication for asp.net web API as is demonstrated in the default single page application template. But now I want to use the same web API from a different site (a different url).
When I make a request to web API AuthorizeEndpoint(by default /api/Account/ExternalLogin) from different site, I get error: invalid_request. I guess the problem is in the redirect_uri value, since changing that to value of site running on same domain as web api resolves the problem.
ValidateClientRedirectUri method in application OAuthAuthorizationServerProvider doesn't get fired. So based on my search in Katana source the error origin is in OAuthAuthorizationServerHandler.InvokeAuthorizeEndpointAsync.
Does anyone else have the same problems or am I doing something wrong?
The Katana OAuth middleware is not designed to be cross application - it is mainly for "embedding" an OAuth authorization server into the business resource.
If you want a proper (free) authorization server - have a look here:
https://github.com/thinktecture/Thinktecture.AuthorizationServer/wiki
The bearer token appears to be a hash into an claims hash, which is local to your application.
We are using a jwt token with a separate validate handler. Works cross application.
Still looking for a better way but for now it works.
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.
What is a good way to transfer an authorization key to a server? I'm building an REST-API right now and I'm stuck how the user can authorize on that api. He will get an authorization key (thats not the problem), but what would be a good way to pass this key to the server? As a GET parameter, as an HTTP Header field, as a cookie?
Which way is easy to handle with most of programming languages (e.g. I want to use the API with php or ajax..)
i suggest to send via HTTP POST, and if possible then encrypt it before sending it and decrypt it on server on need basis
You could use the HTTP Basic authentication scheme, which uses the Authorization HTTP header. With Basic authentication, the client must provide its credentials on each request. so you might prefer the Digest authentication scheme, which is a little more secure.
Without more details, I might recommend OAuth 2.0 with the Client Credentials grant type. Basically, the client uses Basic authentication with its client credentials once to receive an access token, and then it uses the access token on subsequent resource requests. Typically the access token is submitted using the Authorization HTTP header.
OAuth is really an authorization framework, but it provides a good solution for API authentication also, and you might find its authorization tools useful for securing access to API resources. It could be that the Authorization Code grant type is applicable to your use case as well.
Related: Best Practices for securing a REST API / web service
A number of applications support the following method for passing authentication credentials to a server:
https://username:password#www.example.com
Among these applications are both wget and Firefox (but not IE).
My questions are as follows:
Is the ability to pass credentials via the URI an HTTP standard?
Does this method only work for HTTP Basic authentication or will it work for any authentication scheme.
Thanks!
Is the ability to pass credentials via the URI an HTTP standard?
It is part of the URI authority scheme.
Does this method only work for HTTP Basic authentication or will it work for any authentication scheme.
It is on the URL. It will work with HTTP/HTTPS. It will not work with things like forms authentication.