Is it possible to just use cURL to handle the authentication with the Xero API for a private application? I've played with the PHP library and that all works well but I'd like to just use straight cURL commands for the HTTP Requests which it can obviously do, just not sure if I can use cURL to handle the OAuth 1.0a authentication?
If you happen to use Filemaker Pro you can do this easily via the BaseElements plugin from Goya using BE_Xero_SetTokens, and then including the consumer key and your private key as the username and password in subsequent HTTP requests.
Details here.
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'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 have APIs. Some of them are limited to access from third party applications by OAuth.
I also have a web application. Users can login and see their private information.
The API is called from the web application too. My question is what is the good way to access the API with security measures.
1. Third party applications -> OAuth
2. My own web application -> ???
My web application uses session id for authentication. I guess that transferring the session id with HTTP header may be good way but I don't have a confidence.
For exmaple...
$ curl -X PUT \
-H "X-Sample-Application-Id: "My own web application's ID" \
-H "X-Sample-Session-Token: yeoql2dvn7whpm4tbe61viscv" \
If API receive this request, use session for authentication instead of oauth and identify the user....
Any help will be appreciated.
Thanks,
.. I found similar questions
Questions About Consuming Your Own API with OAuth
Update1
Some say JWT(Json Web Token) is good.
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html
Update2
I may be able to use OAuth's "Resource Owner Password Credentials"
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html
Or... "Client Credentials grant" looks much better.
I'm going to elaborate a bit on this, because it's a good question, and there is a lot of confusion around it -- so bear with me here.
If the API you are trying to protect is going to exclusively be used by individuals for server-side apps, and not third-party developers, I'd highly, HIGHLY recommend you use HTTP Basic Authentication to secure your API service.
The way this works is super straight forward:
For your user(s), generate API Key pair(s) that consist of an ID and Secret. API keys are synonymous with username/passwords. Just generate random ID / Secret values using a UUID library.
When you authenticate against your API service, supply those API credentials in the HTTP Authorization header to identify yourself. Here's how it looks using curl:
$ curl --user my-api-keyid:my-api-key-secret https://api.myservice.com/blah
What's great about Basic Auth is that:
It's very simple to implement.
It's a well defined standard.
As long as you are making requests over HTTPS, and you don't publicize your API keys, you should be safe.
Now -- if you're building an API service where you want to authenticate users from a variety of environments (not just server side applications), you really need to use the OAuth2 protocol.
This is what it was designed for.
The OAuth2 protocol can authenticate users in a variety of ways -- but as a result, is quite complicated. Adding OAuth to your site can be a challenge, even if you're using popular libraries / etc.
Here's how OAuth works (a quick breakdown):
The Password Grant
The Password flow in OAuth is where you exchange a username/password for an Access Token (usually a JWT). You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.
This is what most people do when building SPAs with Angular / React, as well as mobile apps.
The Client Credentials Grant
The Client Credentials flow is where you exchange an API key (just like basic auth) for an Access Token. You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.
This is what people do when building server side apps with OAuth.
The Implicit Grant
This flow is what you see when you log into some place like Facebook. You click a button, are redirected to some other site to authenticate / accept permissions, and finally you're returned back to the main site with an Acccess Token that you use to identify yourself. This is NOT ideal for API services.
The Authorization Code Grant
This flow is exactly like the implicit flow, except you get back an authorization code that you then EXCHANGE for an Access Token that you use to identify yourself. This is NOT ideal for API services. It's slightly more secure.
If you are planning on going with OAuth because of your use case, I'd highly recommend checking out an authentication provider like Stormpath. They automate a lot of this stuff, and solve a lot of complexities around OAuth.
Otherwise, give Basic Auth a go!
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.
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.