Develop Reference

JavaScript app to Symfony API rest authentication

I already Googled that, but I didn't found any answer that satisfy me, maybe because it's impossible.
I want to know if I can authenticate a website directly from JavaScript to a Symfony API rest. My goal is to create a script in JavaScript, which make ajax requests to the API (the API accepts cross origin requests) and get some data in the response, but the website(s) needs to authenticate with the API to get this data.
I can certainly use JSON web tokens or OAuth to make the website authenticate as a user, but in this case I need to have some script on the server side of the website and call it from ajax to get the website authenticate and return the token in the response. I don't want to store anything on the website, only put my script tag in the html, to facilitate the installation of the service(it's a widget) for webmasters.
I also know that I can do that with referrer authentication, but I will avoid that, everyone can change referrer in the request headers. I can also put an apikey in the link of the script <script src="mydomain.com/myjs.js?apikey=MY_API_KEY"> but everyone can access the apikey and use it from everywhere.
Is there a way to do that safely?

After some research I think the only solution is what I already done, apikey-referrer authentication:
How to keep API keys secret when using client side Javascript?
How does Google Maps secure their API Key? How to make something similar?

Front-End API Token Exposure

My question is simple and general: when making calls to RESTFUL APIs, whether they be mine or external ones, is it common practice/ok to have the token exposed on the front end? For instance, in the documentation for the Google Maps api, they suggest the following code:
<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap"
async defer></script>
the fact that your API key is exposed on the front end for all to see is ok then? I guess google has has the option to restrict access, so that can solve that, but what about other services that don't give that option?
Is it better to keep my API calls on the backend to protect my tokens? Having them on the backend, I would think, would not be preferred, because they I cannot get the data asynchronously

In short , yes it's possible to use someone else API keys in your site if you can spoof http referer header on client system .In fact you can even saturate his quota completely if you have either of these
Full control over your clients browser (to manipulate HTTP headers it might send to google servers)
You own huge collection of unique IP adresses (try only if you're freakingly rich and only motive you're left with in life is to empty his quota xD)
Idk atm will tell if i learn something more or someone comments something

api-key for client-server communication and security

i need some advice.
i want to build a JS app that will run on a client browser and communicate with ajax with my server.
the problem is that i want to give this client some api-key so i can authorize it on my server.
security wise its a problem because as long that this key is sending through the ajax call, anyone can replicate this call.
i don't want to ask the client to create some proxy server and "curl" the request.
i want it to be directly from the client to my server.
what is the best practice for that except verifying the client by his IP or domain?

You could use something like a JWT.
You create an authentication object
{
apiKey: asd-dfgdf-e3234, // not even necessary (read on)
expires: 12213493434,
ip: "x.x.x.x"
}
You base64 encode it and then sign it with a private key (or hash function on your server) and attach the signature as a base64 string to the "payload".
eyBhcGk6IDEyMzQ1LTU2Nzc4LCBhcGk6IDEyNy4wLjAuMSB9.Tm90IFNlY3VyZSE=
| -------- payload ----------------------------| -- signature -|
Pass this to your client. Every request sends this token. It can be examined and verified to be tamper free (match the requesting IP no key necessary).

Sadly, you can only check the Referer header, and issue API keys with a whitelist of allowed referers.
The main issue here is Referer isn't secure at all: it can be changed. That is, anyone can impersonate a client...
AFAIK, the point is your clients should be able to re-create their API keys, and they should do it once they've realized that someone is impersonating them. And they should keep re-re-re-creating until the bad guy stops impersonating them...
Make it as hard as possible...
One possible approach to make things harder to unwanted clients impersonating actual clients can be using access tokens with expiration.
Also, a good practice can be that one client can request a limited number of access tokens everyday. If these access tokens have a 24 hour expiration time, and there's a limit of 3 or 4 access tokens per API key and per day, if many bad guys try to impersonate one of your clients, well, only 3 will be able to do so.
You can also define a limit of an access token per day. This could make things even harder.
BTW, you can argue that anyone can steal the whole access token too. Well, this is the time to re-generate the API key and get a new one. Finally these bad guys will get tired of getting their access tokens invalidated...
Best solution
Actually, if your API needs to be secure and it's private as you've said in some of your comments on my own answer, there's no choice here: you need to go the server proxy way.
I would check node-oauth2-server to use OAuth2 to secure your API.

Public facing Authentication mechanisms for REST

I am designing a new service that would enable 'customers' to register and pay a per-use type fee for particular searches they perform. This service would be exposed using a RESTFul and SOAP interface. Typically the web service would integrate with the customer's website and then be exposed to the 'public' where anyone would be able to use the customer's website and take advantage of my web service features (which the customer would pay for but have full control of moderating the requests so they don't get charged too much).
I want to design the service that optimises the integration to make it as simple as possible. The web service API will change so creating an internal proxy to expose the web service to the public in some cases is too much of a detractor for customers. So the issue as I see it is creating a web service that balances authentication, security and integration.
Ideal
Not use OAuth
Avoid forcing the customer to create an internal proxy which re-exposes the same web service API I have already.
Be secure (token username/pass whatever and ssl)
Embed a javascript library in customer website - This would be a client Javascript library to make integration steps even easier.
The Javascript library would need to be secure enough so that the public wouldn't be able to simply grab credentials and re-purpose it themselves
Not be too hacky, if possible, so the web service doesn't have to be re-built if Firefox 87 comes out (to be released in as many minutes) and decides to fubar it.
It seems that some kinda of 3-way authentication process is needed for this to work, i.e. authenticates a particular client (in the public), the web service (the customer) and the web service.
Has anyone implemented something kind of similar and how did they tackle a situation like this?
I also understand there is a balance between what can be done, and what would violate cross-domain security, so perhaps the entire web service might be exposed by another GET only interface which would return JSONP data.
/** Addendum **/
I have since discovered a web service that does what I'm looking after. However, I am not confident I understand the implementation details entirely. So perhaps someone could also elaborate on my thinking.
The web service I discovered seems to host the Javascript on the service side. The customer would then integrate their website with the service side by including the Javascript in a script tag, but supplies a key to do so i.e.
Somehow if I add the script to my website it doesn't work. So somewhere along the line the token must be registered to a particular customer domain, and the 'client-lib.js' is actually a servlet or something similar which can somehow detect that the user from the 'public' coming in has actually originated from the 'customer' domain.
Is my thinking right? Is there some kind of http header that can be used this way? Is that safe?
Cheers

First of all - let me provide you a link to another SO question which I answered yesterday - as it gives a pretty extensive answer to a similar question-set.
I am assuming that you are going to charge the owner of the site from which the search is made, and not care so much who the individual user is who makes the search. If that's incorrect, please clarify and I will update my answer accordingly.
Clearly, in any such case, the first and foremost thing you need to do is to make sure you know which client this is on each request. And - as you said, you also want to make sure you're protecting yourself from cross-site attacks and people stealing your user's keys.
What you might consider would be the following:
Create a private key on your side - which only your service knows.
Whenever a new consumer site creates an account with you, create a new shared key which only you and they will know. I suggest creating this key by using your private key as a password, and encrypting some kind of identifier which will let you identify this particular user.
As part of your registration process, make the consumer site tell you what URI they will be using your scripts on.
Now - the way that you both do your tracking and authentication becomes fairly simple.
You mentioned providing a JS library which won't need to update every time FF updates. I suggest building that library using jQuery, or another, similarly supported cross-browser JS foundational library - and letting that wrap your AJAX.
When the client site requests your script, however, have them provide you something like:
http://www.yourdomain.com/scripts/library.js?key={shared key}
On your side, when you receive this request, check the following:
When you decrypt their shared key using your private key, you should not get gibberish. If you do - it's because their key has been altered in some way - and is not valid. This should result in a 401: Unauthorized error.
Once you decrypt the key and know which client site this is (because that's what the key contains) - check to make sure that the request is coming from the same URI that client registered with. This now protects you from someone stealing their key and injecting it into a different website.
As long as the above matches, let them download the file.
Now - when you serve the JS file, you can do so in a way that injects the key into that file - and therefore it has access to their shared key. On each of your AJAX requests, include that key so that you can identify which client this request is coming from again. In a RESTful environment, there shouldn't really be sessions - so you need this level of authentication on each post. I suggest including it as a cookie.
On your server-side - simply repeat the checks of their key on each subsequent request - and voila - you've built yourself some fairly tight security without a lot of overhead.
That said - if you expect a lot of traffic - you may want to come back to this and explore more deep security processes in the future, as rolling your own security matrix can leave unexpected holes. However - it is a good start and will get you off the ground.
Feel free to ask any questions if you need, and I will try to update my answer accordingly.

The best way to go about it is something like this (taking that you want to use javascript hosted on your server and make the include part as simple as it can be):
*user registers on your website and he receives a token for his domain
*the user can include a js file pointing to your server
the js file will be something like:
<script type="text/javascript" src="http://your.server.com/js.php?token=###&widget=xxx"></script>
or
<script type="text/javascript" src="http://your.server.com/js.js?token=###&widget=xxx"></script>
if you will use a .htaccess to redirect
*in the php file check if the token matches the requests domain, if yes echo out the js lib, if not throw a error or something
*in the js you will need to build some ajax calls to your service and stuff to manipulate the HTML (create a widget holder,show some data, etc.)
*also all the calls should have the token, and again you can use the same logic to check if token==server address
EDIT:
The REFERER is sent by the client's browser as part of the HTTP protocol, and is therefore unreliable indeed.
If you want to verify if a request is coming from your site, well you can't, but you can verify the user has been to your site and/or is authenticated. Cookies are sent in AJAX requests so you can rely on that. But this means you need to use something like oAuth
If you want to use this method, you should still check the referrer as well to prevent CSRF en.wikipedia.org/wiki/Cross-site_request_forgery
Ideally you should use a unique token per session per user (per request if you're paranoid) to prevent CSRF attacks. Checking the referrer is just security by obfuscation and not quite a real solution.

Web services API Keys and Ajax - Securing the Key

This is probably a generic security question, but I thought I'd ask in the realm of what I'm developing.
The scenario is: A web service (WCF Web Api) that uses an API Key to validate and tell me who the user is, and a mix of jQuery and application on the front ends.
On the one hand, the traffic can be https so it cannot be inspected, but if I use the same key per user (say a guid), and I am using it in both then there's the chance it could be taken and someone could impersonate the user.
If I implement something akin to OAuth, then a user and a per-app key is generated, and that could work - but still for the jQuery side I would need the app API key in the javascript.
This would only be a problem if someone was on the actual computer and did a view-source.
What should I do?
md5 or encrypt the key somehow?
Put the key in a session variable, then when using ajax retrieve it?
Get over it, it's not that big a deal/problem.
I'm sure it's probably a common problem - so any pointers would be welcome.
To make this clearer - this is my API I have written that I am querying against, not a google, etc. So I can do per session tokens, etc, I'm just trying to work out the best way to secure the client side tokens/keys that I would use.
I'm being a bit overly cautious here, but just using this to learn.

(I suggest tagging this post "security".)
First, you should be clear about what you're protecting against. Can you trust the client at all? A crafty user could stick a Greasemonkey script on your page and call exactly the code that your UI calls to send requests. Hiding everything in a Javascript closure only means you need a debugger; it doesn't make an attack impossible. Firebug can trace HTTPS requests. Also consider a compromised client: is there a keylogger installed? Is the entire system secretly running virtualized so that an attacker can inspect any part of memory at any time at their leisure? Security when you're as exposed as a webapp is is really tricky.
Nonetheless, here are a few things for you to consider:
Consider not actually using keys but rather HMAC hashes of, e.g., a token you give immediately upon authentication.
DOM storage can be a bit harder to poke at than cookies.
Have a look at Google's implementation of OAuth 2 for an example security model. Basically you use tokens that are only valid for a limited time (and perhaps for a single IP address). That way even if the token is intercepted or cloned, it's only valid for a short length of time. Of course you need to be careful about what you do when the token runs out; could an attacker just do the same thing your code does and get a new valid token?
Don't neglect server-side security: even if your client should have checked before submitting the request, check again on the server if the user actually has permission to do what they're asking. In fact, this advice may obviate most of the above.

It depends on how the API key is used. API keys like that provided by Google are tied to the URL of the site originating the request; if you try and use the key on a site with an alternate URL then the service throws and error thus removing the need to protect the key on the client side.
Some basic API's however are tied to a client and can be used across multiple domains, so in this instance I have previously gone with the practice of wrapping this API in server side code and placing some restrictions on how the client can communicate with the local service and protecting the service.
My overall recommendation however would be to apply restrictions on the Web API around how keys can be used and thus removes the complications and necessity of trying to protect them on the client.

How about using jQuery to call server side code that handles communication with the API. If you are using MVC you can call a controller action that can contain the code and API key to hit your service and return a partial view (or even JSON) to your UX. If you are using web forms you could create an aspx page that will do the API communication in the code behind and then write content to the response stream for your UX to consume. Then your UX code can just contain some $.post() or $.load() calls to your server side code and both your API key and endpoint would be protected.

Generally in cases like this though you proxy requests through the server using 'AJAX' which verifies the browser making requests is authorized to do so. If you want to call the service directly from JavaScript, then you need some kind of token system like JSON Web Tokens (JWT) and you'll have to work out cross-domain issues if the service is located somewhere other than the current domain.

see http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx for more information
(How to do API Key Verification for REST Services in .NET 4)