I'm working on writing API for web-project. For identifying API users basic authentication is used. And in order to test API call I can use curl command line tool and write something like this:
curl -H "Authorization: Basic Tm9TY1hETjRGNjIwZ1FwcTZOMENjMHczSjJDTjFlcnM6VmhWM21kUHF1MkIyMjFDaWRKVE4odyYmbyRpTEBsM0U=" http://example.com/api/function
On the test server we have HTTP authentication. I've uploaded scripts with API functionality and now I don't understand how I can make call to the API function on the test server. How I can provide username and password for HTTP authentication and after provide username and password for API?
Basically, you are trying to perform two authentications in a row, with the same method. This is not a scenario covered by [this authentication protocol][1]---so in short, you cannot with standard settings.
The reason why the protocol cannot cater with this scenario is a header clash: The first challenge will use the WWW-Authenticate / Authorization header pair, as well as the second in a single request.
One way to allow for a double authentication requires changes (that you may not be allowed to do):
You could have the first authentication process accept two pairs of headers, authenticate against the first one, and then rewrite the headers for the second authentication process. This should be fine for a test environment, provided the environment contains no security-sensitive data, e.g. customer data. Absolutely a bad idea otherwise.
You could replace the first authentication process by a different protocol. For example, you could deactivate the process and require an SSH / VPN tunnel to access the machine. Then, all HTTP requests could be tunneled and they would just need to authenticate against the second process.
One final thing. I did not know this would not work:
curl --user "test:password" http://stan:uberflow#myserver.com
Both --user and the credentials in the URL use basic authentication, so they step on each other. It may depend on the implementation; in my environment --user has precedence.
[1]: I carefully avoided to say security protocol, as HTTP Basic Authentication is not "very" secure, and it offers poor protection over HTTPS.
Related
I've created a small wishlist project.
I wan't to serve an API for users, which have an API Key.
My webserver run on TLS (HTTPS). It is safe for users to send api key in clear in the http headers like that ?
curl -H "Authorization: api_key MY_APP_API_KEY" https://myapp.example.com
Otherwise, what should I use ?
I would like not to use OAuth2, which is too complex for my little project.
Yes it is perfectly safe.. HTTPS encrypts all message contents, including the HTTP headers and the request/response data.
Is this a Web product?
If so, keep in mind your MY_APP_API_KEY will be fully available in the browser.
If it is a Web product, maybe consider a simple alternative like https://pay2my.app for logins (I'm involved in that OSS project)? Users login browser-side and send their own token + signature to the server: server just validates that.
Otherwise you're already good to go as per the first answer 👍.
I am developing two linux programs, a CLI client and a server communicating via gRPC, and I now would like to authenticate users against a given private authorization server such as LDAP, Active Directory, etc.
I am confused regarding the various possible authentication flows. I think I can't use any classical flow including HTTP redirects since I shouldn't rely on a browser being installed or having internet access. I can't even define an endpoint I could redirect to (servers don't have internet access, and both are behind NATs).
So I was thinking of trying to store user's credentials as a JWT token file in the user's computer and then load it from my CLI client program to include it in my RPC requests and then validate it on the server-side. But, supposing I'm right, then what would be the best standard way of getting this token file?
If you had a browser you could use OAuth and the 'oob' (out of band) method where the CLI opens the browser and after the user authenticates it displays a number which the user copy/pastes into the CLI. This how my flickr backup CLI works. The number they copy/paste is because the CLI has no OAuth endpoint and the number is their access token to allow me to call the flickr api on their behalf.
If you can't use a browser the CLI can just accept a username/password from the user, send it to the server and receive a token in return. You don't really need anything fancy like JWT. A simple UUID would be enough. The UUID 'asserts' that the user is allowed to access the server's other RPC methods. The server would validate the UUID token to make sure it's still valid. If you need user information from the token, the server could do that. Keeps the user information off the client's disk and only the CLI can access that information, if the token is still valid.
So in effect, you need a new server RPC method, perhaps, authenticate, that accepts a username and password and returns a UUID token. All other RPC methods then need to accept that token and validate it before performing the requested function. As part of the server-side authentication process, the server could associate that token with the user information it got from the LDAP server so you don't need to store that information on the client. Lets you encrypt it on the server too and if the client needs it, it asks for it using the UUID token if it's still valid (time to live?). If it's no longer valid, the client just needs to ask for username/password again and the server can re-authenticate the user via LDAP and refresh the token and user information.
gRPC has authentication protocols but the SSL/TLS doesn't seem to match your needs and the OAuth won't work as you don't have a browser. So perhaps rolling your own simple token service (authenticate) combined with LDAP authentication might be a workable option.
I'm developing a solution that has: an Authorization Server (AS), a Resource Server and two clients. The two clients are: a web app with Angular 2 and a mobile app with Angular 2 + Ionic 2. I have started to develop the Authorization Server following this sample https://github.com/Baeldung/spring-security-oauth
For both the clients, I have decided to use the "Password Code Grant" because the client are trusted by the AS.
But now I have a problem storing the "client secret code" on the apps. Because the API (.../oauth/token) is secured by Basic Authentication so every time that I ask a token to the AS I need to send something like that:
curl.exe -v -u client_id:client_secret http://localhost:8080/backend/oauth/token -d grant_type=password -d client_id=client_id -d username=admin -d password=admin
So, the questions are:
Where I can store safely the client secret code on the apps?
Is it safe to remove the Basic Authentication from the oauth API?
Have I use another code grant type?
Thank you,
Paolo
Applications running in a browser (Angular) are not able to keep their secrets safe, so I would choose the OAuth2 Implicit flow. The implicit flow requires the use of HTTPS for communication with your Authorization Server, since the tokens are transferred over the network.
You should not remove the authentication from the token endpoint - it would compromise other flow types. For example the authorization grant flow doesn't require the client to be served by HTTPS and the auth code can be visible to anyone, so the token endpoint secret is important there (the Resource Server must ask for the tokens using HTTPS).
Using the implicit flow, you will have to check the validity time of the access token and request a new one before the current one expires. For example using the prompt=none auth request parameter.
I've setup security in my RESTFUL WCF services using Custom Basic Authentification (thus desactivating the iis Basic Authentification and not using Windows Accounts Login at all; my service is hosted by iis) using the following link.
blog link
I understand the consumers have to implement a client to pass credentials in the request header.
It is 64bits based encoded and we can see credentials passing in firebug network tab while debugging (it is always the same string encoded <=> same credential .......)
So, in addition, to enforce security I will add SSL to encrypt the url :
https://myrestfulserviceurl.com/Method
Now the consumers ask me why we don't just put the login and password in the url request i.e
https: // myrestfulserviceurl.com/Method?login=XXX&password=YYY
(also combined with SSL)
Thus the change requires to add login and password as parameters in my Operation Contract and call a method for authentification in my method "Method".. etc etc
My question is :
What is the difference (both scenarii will use ssl) between Custom Basic Authentification (credentials in request header) & simply passing credentials in url in param ?
I mean : I'm just asking myself why I do bother to implement Basic Authentification. Passing credentials in url or in header look similar : it's passing stuff in the request. But talking in term of security, it looks the same ?
Basic Authentification looks not more secure excepted the 64bits based encoding.
Correct me if i'm wrong.
I am just looking a reason why implementing Custom Basic Authentification.
Any idea/advise?
Thanks
The main difference that comes to mind is to do with how visible the data is and how long it is likely to be retained.
For instance, assuming SSL is terminated at your application server, values in the get parameters are likely to be automatically logged to your file system (in request logs for instance). Having usernames and passwords in there is not ideal as it makes it much easier for them to be leaked.
If SSL is terminated at a loadbalancer or some similar proxy, then the usernames and passwords could be saved in request logs on servers you may not be thinking about and probably have less control over.
By contrast, the Authentication header is much less likely to be logged to places you're not expecting.
I thought about doind this myself and decided against it because i wanted the Restful URL's to focus only on the operations and keep security out of it, for example I might want to re-use the same code on a different application.
Also Im not sure but i think there could be a security implication concerning replay attacks, if someone obtained the link then they could execute it in any http client. If you used the authroisation attribute in the http header you could avoid this by putting an expiration on it. Also i think its better to hide this information from the html page body.
The dude who wrote this http://lbadri.wordpress.com/2012/07/30/anatomy-of-a-simple-web-token-swt/, which is taken from his book "Pro ASP.NET web Security". Gives a pretty decent example of creating a token which you could then use in the http header "Authorisation", like: Authorization: Basic d2FsaWRAGssSGZ21haWwuY29tOn236dhbGlk
What is the best way to ping the GitHub API to ensure that a user's credentials are valid? I would like to simply call the API while passing the credentials via Basic Auth. I cannot find a suitable docile request that requires credentials.
To verify an OAuth token you can use this endpoint:
http://developer.github.com/v3/oauth/#check-an-authorization
To verify a username-password pair - just try making any API request with Basic Auth (e.g. just make a request to https://api.github.com):
http://developer.github.com/v3/#authentication
However, notice that making a few requests with a bad username-password pair will temporarily lock you out if those are made within a short period. Providing a separate endpoint for verifying username-password pairs that doesn't have this lock-out feature would be a security risk.