Develop Reference

Twitter oauth without server, or server in different domain

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.

How to secure the JavaScript API Access Token?

There are numerous online resources which provide JavaScript APIs to access their services. To be more clear, I will base my question on the example of MapBox, but this applies well to many other services in various domains.
When someone wants to use such a service in a web application (like the map imagery from MapBox for example), they typically need to Register/Sign Up and obtain an access token to access the service.
Now, if I would use the API from the server side - there is no issue: I know my token is stored securely somewhere on the server and is only exposed upon communication between my server and the service provider, which is OK as long it is HTTPS. However, in case of a JavaScript API (for example if I use Leaflet to render a map from MapBox), I am supposed to have my access token in a JavaScript which is exposed to the user's web browser - and so it makes it extremely easy to find someone's access token. My users, or in a case of a public service, literally anyone, would be able to find the token in the browser's "Dev Tools".
This token however, as for me, should be considered as a sensetive data - service usage is tracked based on the authentication this token provides. If you pay for the service based on its usage it becomes critical, but even if you don't (like, if you use a Free/Starter/Non Paid plan) - service usage is limited and I'd like to be sure it is only me who uses it.
Is my only option a proxy via my own web server?
Is there a way to secure the access token used by a JavaScript API to access an external service, provided that JavaScript is executed in a user's browser?

Restrict Access with CORS
Make your web server return the access tokens on an ajax request from you javascript with CORS setup. Token can be captured with this method visiting your app.
Provide Tokens to Authorized Users
You can also add authentication on your webserver to provide limited access to the users you allow. Token can be captured with this method but only by authorized users.
Proxy Requests
The only way to completely protect that token is to proxy the requests through your server. Token cannot be captured with this method. Note that this may be against terms of service.

Javascript API tokens (and all client tokens, in fact) are always visible to the client (unless using them only server-side, as in node). There is no way around that. As you mentioned, the only way to truly secure an API key and keep it private is to store it in the server, then request the server to make the request on the client's behalf.

5 years later, this is not necessarily for the original poster but for anyone still interested, Mapbox now allows you to easily restrict tokens by domain(s):
https://account.mapbox.com/access-tokens (assuming you are signed in)

I will speak only about map imagery APIs like Mapbox, it seems that unfortunatly only services like Google Maps, Here Maps, Bing Maps etc offer ip/domain filtering by service provider or this type of security, all offers based on OSM i met don't propose it. As Justin Poehnelt said the only reliable way is to build a proxy, but it's usually forbidden. I find this in the ToU of Mapbox:
You may not redistribute Map Assets, including from a cache, by
proxying, or by using a screenshot or other static image instead of
accessing Map Assets through the Mapping APIs.

You may like to read up on CORS headers
These allow you restrict which domain can call a remote web service.

How to communicate securely (with proper authentication) to a 3rd party api on the client?

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.

How to share authentication between website and service for Ajax

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.

Signing webservices api calls with javascript

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.