I have a site on angular (e.g: app-client.com), where every piece of data comes from another REST API site (e.g: app-api.com).
The app-client.com is only a bunch of html, css, and javascript files, and no server-side scripts (None of these: PHP, ASPX, python, node.js). How can I add a feature to use twitter API in behalf of my user?
I know some oauth providers have 'implicit grant oauth', does twitter has it?
Is there any way (even hack-ish is welcome) how to use oauth or, at minimum, get user access-token in javascript?
The only way is accessing Twitter API from your app-api.com, if possible. Twitter don't have any client side API yet, because of oAuth scheme that require consumer-secret etc that must be securely store in server side.
Related
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?
I am developing a RESTfull web services. This web services will serve as a Web API to the outside world to get some data from our system. So, it will be consumed by other external clients: Mobile Apps, JavaScript clients, etc. For security, it will require Basic HTTP Authentication: user name and password sent as clear text over HTTPS.
So, I want to put together a proof of concept JavaScript application to demonstrate how one would use this API. But I don't want to hard-code user name/password in JavaScript code, since it can be viewed in page HTML source. In fact I don't want JavaScript to be involved in Authentication at all. So, I was thinking having another web page for server to server authentication. So that client's server sends credential to WEB Appi server, then Web API server issues a token valid for one session only, after that Client server uses this token in JavaScript.
Is this the right approach? If not, what's the "best" solutions for this scenario? I am sure this was done before. Any articles, or code samples will be much appreciated. Thank you
Consider the usecase in which a website uses a paid analytics package to track user behavior on said site.
In that case the website needs to securely communicate with an API of the analytics provider (all clientside through javascript).
How can this be done securely? To my understanding of the various authentication protocols a secret token is always needed to setup a secret-handshake between client and server. Using oAuth1a this is all packed in HMAC, etc. but still the secret must be available.
Given that:
the secret code must be available to the client in javascript to do authenticated calls
javascript on the client can obviously be inspected by anyone
How would you keep the secret safe? It seems you can't, but how then do all these paid 3rd party services which communicate through clientside JS keep things secure?
As stipulated by the referenced answer below, it seems Google Maps API is doing this with the HOST header which apparently (?) can't be spoofed.
How does Google Maps secure their API Key? How to make something similar?.
Thus, having a sever-side map which uses a map of <apikey -> allowed HOST headers> would do the trick.
I have a WebSite (MVC 4) and WebService (Web API). WebSite has an authentication cookie and it decrypts that in order to send a secure token on to WebService when the WebSite server side code calls the service. That works fine.
However, the WebSite has JavaScript that I would like to call the WebService directly. I've tried sharing the MachineKey and Auth information, but the cookie is not carried across the WebApi.
My fallback is to route all calls to the WebService via the WebSite; but that's ugly and slow.
Any ideas?
The correct answer is Darin's. In order to share a login cookie between a services site and a web site, they will both have to be on the same domain; so e.g. the services site could be at
http://svc.mysite.com
And the web site could be at
http://www.mysite.com
Then the browser will allow the two sites to share the same cookie.
An alternative would be to have the site authenticate to the services site and get a token of some kind it could pass to the javascript. However, unless you were running on HTTPS this would be highly insecure, as the token would be available "in the clear".
A final mechanism (and the most common solution I think) would be to route all API accesses through the web site, but this is not ideal in many circumstances.
I'm looking for a nice pattern that woud help me to fully sign my api calls with javascript (here for some example, vimeo) after some oauth connect retrieved authorization identifiers.
Using ruby with omniauth, what I'm looking for would be to retrieve the url that gets called when you do a ModelName.{generateTokenMethod}.request(:get,{url})
It is possible. There are a handful of oauth 1.0a libraries for javascript (You could try looking at some node.js code as an example).
The problem with using oauth in client-side javascript is that it will expose your client secret to anyone using your web service.
Anyone who has your client secret can make requests on behalf of your application, and lure users into generating access tokens by masquerading as your application.