Basic Auth + Rest API - javascript

I am developing a Rest Api, that will be consumed from a javascript.
So If I use basic authentication, the user and passoword (encoded in base64) will be visible on the java script running on the client browser.
How can I protect my API? Do I have to user CORS (https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) to protect it?
Sorry for the newbie question.

Notes from comment conversation:
the webservice is authenticated from another site; is not open to just any user.
I think you'll have to individuate the authentication, which I don't think is possible/practical with basic auth. I'd recommend some sort of freeradius + OAuth, given that you have users authenticating on other sites.

To protect an API there are different authentication based security techniques suggested by APIGEE, stormpath.
OAuth 2.0
OAuth 1.0a
You should ideally avoid basic authentication, that not one of the best practices.

Related

Firebase in Cordova/Phonegap: Log in using Email/Password from within app?

I'm running a webview from a cordova app and want to authenticate a user, I know they have the OAuth strategies but I need to use the email/password combination.
I'd like to keep things simple but may end up having to generate a token.
Open an InAppBrowser that loads an auth flow for firebase
Listen for that auth flow to be completed using this method: http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
Grab the result from the webview again and insert it into the webview firebase instance
I'm guessing that's not possible due to security.
My app is using Amazon login (required) so my alternative would be:
webview loads InAppBrowser with our external url
that loads Amazon auth, then generates a token for Firebase
webview listens for token and grabs it, stores it in localstorage
Edit:
In the firebase docs on logging in with a username/password, I see it returns a token for the session and more information in the authData object:
https://www.firebase.com/docs/web/guide/user-auth.html
Could I then take all the information from that object and send it back over to the cordova webview and then populate that Firebase ref with the information?
Some answers from the wonderfully helpful support at Firebase:
First:
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
My response:
So, how is that secured? If anyone can make a request to sign up from a
cordova webview (which comes from no specific url, just the app iteself)
then I can't secure from which url people can sign up from? So any site
could use our url "xxx.com" in their config and start registering
users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you
guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app?
Is it somewhere in localStorage I can check? I'll have to run some tests.
And final response:
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.
This is a topic of interest to me too as I have implemented something similar , twitter digits (native android) + firebase custom login in webview.
I think, as recommended by firebase, you can use other authentication providers and then the firebase custom login.
Do you use the Amazon login in android native code ? If so after login, then generate a JWT token for firebase and use it to access firebase.
If all code is in Html/js app, then maybe you can use custom login and generate a token on your server after making sure its logged in to the Amazon.
The trouble with Android hybrid apps is the following: the JWT token (for firebase) should be created on secure system (eg. server side) not with android java code, other option for hybrid app is to do a http request to generate the token, but I find that less secure, anyone would be able to get a token by finding the URL, than I resort to generate token within android app code, you can change security key/seed for token when doing new releases.
In summary, I don't think firebase studied the problem of mobile hybrid apps.

No Authentication Pop up with Tumblr Like <a> link

As of now I am building out a custom Tumblr page which is basically aggregating post content into 1 page.
Problem is, we can't use the Tumblr tags for the Like, we have successfully gotten the Reblog to work, but when ever I try and use an hrefed to this pattern,
'http://www.tumblr.com/like/'+oath+'?id='+id'
and /unlike/ for unliking the post.
I can't get anything but an access denied page to come up.. Shouldn't I at least be seeing an authentication pop-up of some kind? Not sure what else to do here. Need to get this LIKE functionality working, and using the Tumblr {like button} is not an option since we aren't using a {posts block} rather pulling all our content in via JSON API.
Found an answer!
So let me break it down for you all.. I am just going to run down all the issues and caveats that were discovered while I was hacking away at the Tumblr API. In most cases you will not find any of these answers on the inter webs. If you do, they most likely will just be my answers to my own questions that I posted to the Forums.
A Tumblr Application is defined by any page template either hosted
by Tumblr or not that will be using the Tumblr API. Applications
must be registered with Tumblr at:
https://www.tumblr.com/oauth/apps
All Tumblr Applications upon creation are given a set of keys for
accessing the Tumblr API. OAuth Consumer Key aka API Key Secret Key
The Tumblr API is divided mainly into two different types of
methods. The third being “Tagged” which is for pulling tagged posts
from the Blog or the User.
“Blog Methods” which only require the submission of the Consumer
Key. “User Methods” which require a full OAuth signed request which
meets the OAuth 1.0a Protocol. The “User Likes” returns a maximum of
50 records at a time. This is not documented in the Tumblr API
docs.
Currently the Tumblr API documentation directs developers to use one of the many open source API clients. However, all these clients seem to be Server Side applications. For providers, such as Tumblr, which support only OAuth1 or OAuth2 with Explicit Grant, the authentication flow needs to be signed with a secret key that may not be exposed in the browser.
HelloJS gets round this problem by the use of an intermediary webservice defined by oauth_proxy. This service looks up the secret from a database and performs the handshake required to provision an access_token. In the case of OAuth1, the webservice also signs subsequent API requests.
HelloJS - http://adodson.com/hello.js/ is the only client-side Oauth library that was available and free. There are many services out there that charge on a per-api hit basis to serve as a proxy.
The HelloJS OAuth Proxy is available at: https://auth-server.herokuapp.com/
Login to the OAuth Proxy is done using one of the following social account credentials: Google, Windows Live, Facebook, or Yahoo.
OAuth Proxy serves as a secure “man in the middle” allowing for the “Secret Key” to be securely stored while still allowing for Client-Side OAuth authentication.
HelloJS features a special Tumblr Module - http://adodson.com/hello.js/demos/tumblr.html
HelloJS utilizes the new Javascript Promises asynchronous functions specification - https://www.promisejs.org/
Javascript Promises have some unique rules when it comes to passing objects received from an asynchronous AJAX call.
With everything is done in the callback.
What jQuery calls a promise is in fact totally different to what everyone else calls a promise.
Hope this helps for future Tumblr integrations.
John

PhoneGap and OAuth2

I am developing a PhoneGap application and require my users to sign in through Google with OAuth2. Is this possible directly through JavaScript? I have almost no experience with JavaScript (and jQuery).
What are the options? I have thought of a cumbersome alternative which involves posting the username/password to an application I have hosted on a server which then takes care of logging in. Then the PhoneGap app will have to ask the server if the authentication was successful. However, I was hoping there would be a simpler way.
What is the best way signing in through Google on a PhoneGap app?
I have managed to get it working! I'm posting my thoughts here because I had a hard time finding the answer after hours of searching the web.
The important steps are:
Make sure ChildBrowser works properly
Setup a function that will listen to page changes
window.plugins.childBrowser.onLocationChange = function(fooUrl) { console.log(fooUrl); }
Build the URL with the query string as described in this tutorial
Point ChildBrowser to the URL
When the user logs in, you will be able to extract the session token from fooUrl
If you still don't know how to do this, have a look at this Android app.
(There is a lot of code, and it might seem overwhelming, so I suggest only going for this as a last resort)
Google will not allow you to perform direct authentication by handling the user credentials directly. Instead Google wants you to perform an authentication protocol, typically OAuth 2.0. Other popular authentication protocols you may hear about is OpenID 1.0, 2.0, OpenID Connect, SAML 2.0, ID-FF, etc. These protocols will redirect the user to the Identity Provider (Google, in this case), and send you back with an assertion that you may use to trust the user. With APIs, like Google, you would make use of the authorization functionality of OAuth, which provides you with a token that you may use with all Google APIs after authentication.
A good introduction to how OAuth 2.0 works
With PhoneGap and mobile apps, things are a bit different than the typical OAuth setup.
In your case, the browser is in a controlled environment, your app, and you may
select to redirect the user to Google Authorization endpoint using the main view,
select to open a ChildBrowser with the Google Authorization endpoint, to not lose any state on your app.
to somehow open Safari or another browser with the authorization endpoint, and register a custom schema handler, to redirect the user back to your app after authentication.
These examples are vaguely mentioned in the OAuth 2.0 specifications, but there are no aid in what is the best or optimal in a specific use case. Often the best possible option is not perfect (from a user perspective).
I recently wrote a tutorial on how to make this work with Phonegap and ChildBrowser for iOS.
OAuth 2.0 Guide for Phonegap using ChildBrowser and JSO

Twitter OAuth with Javascript

I'm trying to make a Twitter client with Adobe AIR, how can I successfully use OAuth with Javascript? I mean, I've used jsOauth but it seems to lack the oauth_signature somewhere...
One thing you can try is you can use the approach that is described in the Facebook developers section dedicated to authentication. You want the section that is called "Client-side flow".
In a nutshell they propose that you make an application that will redirect the page it is loaded in to a special URI with it's app_id and backurl in the query parameters. Once Facebook manages your app's permissions, it will redirect the user back to your page with a special access token in a URI fragment, e.g. http://example.com/my_app_page/#token=foobar. This way only your script on the client side can access this token and use it to make requests to the Facebook API.
go have a look at streamie, a twitter client based on node.js. In the source, you can find an extremly good implementation. It's done by cramforce. You find it on github:
https://github.com/cramforce/streamie
jsOAuth uses the Authorization header to pass the OAuth relevant data to the API service.
If you are having issues, by all means email me I'll be happy to look at your code. jsOAuth isn't flawless, I'm fixing bugs as they come up.
Theres a boiler plate for PIN based client auth here: https://gist.github.com/1071227

What is OAuth authentication?

I am developing an iGoogle Gadget. I have to access the spreadsheet data of logged in user. How do I implement an OAuth for it?
You have to become an OAuth Consumer of the Google services - they are the OAuth provider in your case.
There are a lot of open source implementations of the protocol in various languages, but I would suggest to read through the RFC if you want to implement it - it's clearly written and not very long.
The official site has good reads and links too:
http://oauth.net/
Basically it's a protocol that exchanges a little bit of data between you (your application aka the consumer), the provider and your user with internal HTTP requests between you and the provider (exchanging tokens) and some redirects through the user's browser between you and the provider again.
Also, you as a consumer will have to store some tokens and data regarding these interactions. It's not very complicated and in the same time is very interesting thing to implement. I learned things about security, request signing, some http details and headers. And if you already know these things, then you will do it a lot faster than I did :)
OAuth is just an API that Google gives out to developers to let them authenticate Google accounts in other manners other than just going on google.com - for example through a programmatic way.
Authentication is the basis of it, but through OAuth you're able to retrieve lots of information from a specific Google account (calendar info, contacts etc.)
To implement this you would need to read more on their website:
https://developers.google.com/identity/protocols/OAuth2

Categories

Resources