in my project, I am calling webservice with http get request.
API key is also there in http get parameter.
in j2me devices before connecting to the internet it is showing the URL and asking for permission to user.Here user can easily see my api key.
and i don't want to store api key in my application also.because using decompiler
anybody can get api key from applciation.
So my question is where to store api key and how to use it for calling web services?
If the API key is required to use the webservice, then you MUST store it somewhere in your app...By the way, you can store it in some kind of an encrypted way, so a simple decompile does not reveal it.
If the user should enter the API key, the you can store it in the standard RMS store outside of your app, again maybe encrypted.
An for the URL issue, use HTTP POST request instead of HTTP GET, and send the key in the post data.
You could encrypt the api key and store it as you do just now and then POST it to the web service.
Related
I am building a API suite to connect to our application. Each user will have an unique API key which will be passed in the Header.
I am here to ask, what is the best way to authenticate the user? I donot want the user to pass the API key without any encryption ?
I am passing the API key like this :
$headers['x-axpr-auth'] = '<API-KEY>';
Since, I am building the API myself, I have the flexibility to use different encryption/authentication techniques.
Using HTTPS is pretty much mandatory in this case so I'm going to assume you (will) do that.
If you have an API key with long-term validity, then you should consider using some kind of "temporary token" with (very?) limited validity - so the attack window is much smaller.
This is similar to using Basic Authentication (sending password with every request) versus sending credentials only once and using session cookie afterward.
You should look at existing authentication/authorization schemes - OAuth2 (with access and refresh tokens) may be relevant since you're building APIs. OpenID Connect builds on top of OAuth2 and provides a proper authentication layer.
Apart from that, it's uncommon to explicitly encrypt API token in an HTTP header, since the whole communication is already encrypted using HTTPS.
I have a react native application that I want to make API calls from. I am getting confused about how I should be authorising these calls on the node back end.
Method 1:
User logs in to application and authenticates, I then return a JWT with refresh token. This is then stored client side / in react native app and is sent upon each request. If token expires, then refresh using refresh token.
Method 2:
Create API key for each client. When a user creates an account, I create an API key (or maybe access key and secret key like AWS does) and send that with each request.
Is there a preferred / recommend method out of these two? Perhaps they are not mutually exclusive? Do I still need to provide an API key to my react native app so that it can make API calls and then I use JWT for authenticating users?
In my personal opinion,
You may go for the Method 1, since it is not secure to store / create API keys or Secret keys on the client side.
JWT are more secure, you may read the following article
In the Method 2, you will most probably try this approach
Generate Api key based on client IP or the device token, whatever suits you, and set an expiration time including the AES techniques, then decrypt it on the server, check the client's IP against the requestor IP and also the expiration time.
Complexity and time taken to do Method 2 is much more that Method 1, also considering I might have not covered all the security use cases.
Do I still need to provide an API key to my react native app so that it can make API calls and then I use JWT for authenticating users
You can make the http calls normally. The recommended way is call your token generation api and then authenticate other valuable api's based on that token if you're using JWT
Hope it helps.
I noticed that a GET on a notification feed responds with a next attribute containing the API key. Not the secret, just the API key.
I'm curious whether this is safe to expose to an end user?
Example:
"next": "/api/v1.0/feed/notification/user8/?id_lt=8a4ba960-76fc-11e7-8080-800139637857&api_key=blahblahblahblah&limit=1&location=unspecified&offset=0"
The data payload you send to any of our API endpoints is encoded using your API secret into a JSON Web Token payload in the header for most calls. And guessing your very long API secret to properly encode anything would take an awfully long time, so yes we feel it's safe.
Also, you cannot log into the dashboard using your API credentials in any way so your billing information is safe (we still recommend turning on two-factor authentication in the dashboard though)
I'm developing a chrome extension using maps API which autofills the address in the address fields of the current page. For testing purpose, I'm currently using my own API key. But I see using this API key I can hit only 25000 requests per day. So I thought of using the user's API key, whoever uses this extension. Using OAuth, I can get the user's consent for accessing his information but can I get his API key and use it that way? I have set up a server so that I can store the user's API key to be used again. Also for the user' consent, I use my API key and client id. Is it possible?
I have noticed that some API have you pass an API key as a url parameter while others have you pass it in the HTTP HEADER. I am developing a web-based application that is going to rely heavily on a REST API and right now I am just having it so the API KEY is pass through as a url parameter.
My question is whether or not one of those options is more secure than the other?
In both cases, the API key will be passed unencrypted. So both are insecure unless you use HTTPS.
In practice, HTTP header turns out to be a little bit more secure because -
The url gets stored in browser history
The url gets stored in access logs on the server side
Aside : A REST API over the web cannot be secured unless you ask the user to login with his credentials. Anybody can easily identify the API key and make requests to your server.
EDIT :
In response to #segfault's comments -
A website user generally does not enter an API key. They enter their user name and password, and this is traded to get the API key or access token as it is typically called.
If you force your users to enter the API key instead of user name and password, well, it'd be secure. But as I said, I haven't seen any serious application do that.
More specifically, I meant "If a backend API expects an API key, and you are making AJAX calls from the browser, and you don't ask the user for some sort of credentials, you are insecure"