I've been looking into ways to handle authentication and CSRF protection in calls to a REST service (e.g. Angular talking to a REST api exposed by Rails). I've been reading through things like this discussion of protecting against CSRF over REST apis in Rails, this related so post, and this suggested solution as well as looking at the Angular docs on preventing CSRF and how various REST apis do authentication. After all this, here are the general cases I am seeing:
You want to make AJAX calls to a REST endpoint in the context of an existing site with an existing cookie-based authentication/session scheme. In this case, it makes sense to let your AJAX calls use the cookie-based authentication as well, and include an "X-CSRF-Token" header in the AJAX requests to prevent various tricky Flash/Java/redirect-based CSRF attacks.
You want to expose a full developer API for your application, allowing others to create apps/plugins/etc that interface with your backend. In this case, it is preferable to set up API IDs and Keys for API customers, and to use OAuth or something to let 3rd party applications access user data. This has the important benefit of users being able to manage what 3rd party apps can access their data, etc.
You want your own rich client or mobile app to be able to access your own backend. There is no existing cookie-based session management, but you do not necessarily need the flexiblity of (2). In this case, it seems like it makes sense to use something like Devise's "token_authenticatable", to simply store a token in a cookie or local storage in the case of js, or in local app data for a mobile app. This is like how Parse does it (but I would add the ability to expire those stored tokens...)
Is this all basically correct? Am I missing anything major? To me it's all just a bit confusing because of the different use cases a "REST API" can have...
