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.
Related
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.
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.
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
I want to post a http document that is password protected.
It has a username and password login page before you can access the actual document.
I tried doing this
curl
-u username:password
"http://localhost:8983/solr/update/extract?literal.id=doc900&commit=true"
-F stream.url=http://somewebsite.com/docs/DOC2609
but it just indexes the login page only.
My guess is that the authentication method this page of yours uses is not one of the HTTP authentication methods that curl supports out-of-the-box.
The HTTP authentication is basic -- some might say trivial -- and it is fundamentally insecure in its most basic form (literally, 'basic' mode HTTP authentication sends the users' password over the wire in plain text, as one of the request headers). I only ever see it used in conjunction with HTTPS, and even that's pretty rare these days.
HTTP authentication is generally eschewed in favor of either an HTTP PUT or POST request over HTTPS, usually fortified with some kind of cross-site request forgery (CSRF) prevention measure, or an OAUTH2 strategy (which typically defers the issue to the authentication broker's implementation).
Your problem is, curl doesn't know about any of this. If you program in python, you may find the requests package helpful (and more modern than curl in its design to boot). Solr won't care either way, if you are calling its HTTP API properly.
We're trying to test an API that requires HTTP Basic Access Authentication credentials (http://en.wikipedia.org/wiki/Basic_access_authentication) in the request.
Ideally, we could just test the API using a web browser by putting all API parameters in the URL querystring, but we haven't yet found a way to encode the HTTP Basic Access Authentication credentials (username and password) in the querystring.
Does anyone know a way to do this?
Thus far, we've tried:
https://username:password#mydomain.com/
...without success.
username:password#url authentication has been disabled in many browsers for security reasons.
For example in IE:
Internet Explorer does not support user names and passwords in Web site addresses (HTTP or HTTPS URLs)
As far as I know, there is no way to circumvent this if this is blocked. It's possible that this can be turned of in Firefox using a setting in about:config. Or use some other browser that doesn't block it - I don't know which ones do and which don't.
Alternatively, consider building a quick web form that submits the option to a server-side language (e.g. PHP) that makes the request, or use a command line client like wget to send the requests. The latter might even be easiest