gistfile1.md

Discussion: Getting started with client-side applications.

Note: While my stack consists of Laravel (4/5) and AngularJS, i don't want this discussion to become a language or framework flame war, let's keep it respectable.

I would love the result of this to become an incredibly helpful blog post & guide.

Hi guys, i'm currently in the throes of (among other things), writing a client-side application to interact with an API (that i control). And there's a few things that confuse me, and i'd love to start an open discussion on the best patterns to use when building client side applications in order to achieve some of the following:

Securely authenticating users.

Authenticating for a client-side application.

That means that no information that should not be shown to the user (tokens, application keys) is visible or hard-coded into the javascript or HTML.

Currently, my application uses a cookie to store a user's API key after an initial call to a secure authorisation endpoint, but the idea would be to move to OAuth in the future. Are cookies the way forward?

Private methods.

What is the best way to ensure that only 1st-party mobile/web applications have access to certain 1st party private API methods? for data that can't be processed on the client

Gotchas & Considerations

Is there anything else that anyone frequently forgets to do when building an API for consumption by a client-side framework, or are there things people often miss when building their first client-side app? I'd love to hear about them.

Code examples are encouraged and appreciated!

Re: Private methods

CORS is probably your friend here. I would create a route filter, and route group for routes that should only be accessible via your 1st party web/mobile apps. For web, it'd just be a matter of specifying which domains can access these routes through CORS. For mobile (if it's a native app), you might need to create a secret key that gets passed as a header or something.

@syropian thanks, i was thinking the secret key too - essentially an application key that has 'access' to certain API methods that 3rd party users would never be able to enable for their applications.

CORS is a good shout too, nice idea!

I am writing a Laravel (REST API) / AngularDart (Application) for my employer at the moment.
So this interests me greatly as to the most secure way of handling application authentication without people copying the application key.

A friend on twitter is currently writing a comment about Proxying requests to prevent that i believe :) Stay tuned.

just use OAuth2 and make use of scopes. Your frontend javascript app would be a client of the backend. In a POST to your /access_token endpoint you could check the origin of the request and only issue tokens to your domain. Once a user is authenticated you can check if the client they were authenticated through has certain scopes for doing different things. See this example.

We generally serve all API request via a proxy server, which is also handling the initial render of the page. This allows for security to be at the server side. So we make API requests to our sever, which then makes HTTP calls to the third party API, we can then handle sending request headers, and security on the server.

But, we have implemented a client side solution before using crypto-js to handle secure keys (https://code.google.com/p/crypto-js/)

Found a good article here: http://billpatrianakos.me/blog/2013/09/12/securing-api-keys-in-a-client-side-javascript-app/

Thanks @matthewroach and @thecrowflys

may also want to check out this post http://alexbilbie.com/2014/11/oauth-and-javascript/

Having a read of @dadamssg's suggestion.
Good article thus far.

This has been very helpful for me. Thanks.