Basic guidelines for API authentication in an iOS/Ember.js app?
70 views
Skip to first unread message
Andrew Havens
Jun 3, 2015, 8:29:00 PM6/3/15
to rails-a...@googlegroups.com
It seems the topic of authentication has been avoided in this group and as part of the rails-api gem. I understand there are different implementations for different use-cases. But in my case, I'm building an Ember.js web front-end and native iOS app backed by a Rails API. I started working with the default Devise installation (using cookies), but I'd like to know what you would advise if you were building this. A list of general guidelines would be helpful (e.g. don't use session based auth, use ___ instead because...etc).
-- Andrew
Hugh Francis
Jun 4, 2015, 9:19:05 AM6/4/15
to rails-a...@googlegroups.com
Hi Andrew! I think the reason it hasn't really been addressed formally is because there's multiple ways to go about it, and it often depends on your use case and team.
Personally, I'm of the opinion that when you're building an API driven app, the API should be purely "transactional", ie: all of the information for the API to respond should be packaged into a single request, using both the headers and the request body.
In a case like this, you persist something like a user token to the clientside app (localStorage), and then package it into each request as a header. That way your API can load the user against say their ID or email and respond appropriately to the request. Something like cancancan is good for managing different user roles with this methodology.
Using cookies implies that the server is persisting and loading some state to do with the requester; meaning you have shared state in both the request and server.
Splitting state generally means more complexity - so if youre doing this you'll want to do something like setup the client side state on each page refresh or app load, so a sessions endpoint will be useful.
What I can tell you is that persisting session information on both the clientside and the server is a bad bad idea. Not only will your requests and server share state, you'll also have two different snapshots of the same session that can easily go out of sync. I can't think of a good reason to ever do this.
Hope this helps!
Personally, I'm of the opinion that when you're building an API driven app, the API should be purely "transactional", ie: all of the information for the API to respond should be packaged into a single request, using both the headers and the request body.
In a case like this, you persist something like a user token to the clientside app (localStorage), and then package it into each request as a header. That way your API can load the user against say their ID or email and respond appropriately to the request. Something like cancancan is good for managing different user roles with this methodology.
Using cookies implies that the server is persisting and loading some state to do with the requester; meaning you have shared state in both the request and server.
Splitting state generally means more complexity - so if youre doing this you'll want to do something like setup the client side state on each page refresh or app load, so a sessions endpoint will be useful.
What I can tell you is that persisting session information on both the clientside and the server is a bad bad idea. Not only will your requests and server share state, you'll also have two different snapshots of the same session that can easily go out of sync. I can't think of a good reason to ever do this.
Hope this helps!
Benjamin Fleischer
Jun 4, 2015, 10:53:51 AM6/4/15
to rails-a...@googlegroups.com
A common solution in ember-land is https://github.com/simplabs/ember-simple-auth (which has a devise plugin for it as well).
In general, I think you might get more bang for your buck on the question by
- searching http://discuss.emberjs.com/ and maybe joining one of the ember slacks e.g. http://discuss.emberjs.com/t/best-practice-for-loading-and-persisting-current-user-in-an-authenticated-system/6987 https://ember-community-slackin.herokuapp.com/
- looking at discussions of authentication /authorization over an API without worrying whether it's Rails or not. https://developer.github.com/v3/#authentication http://jpadilla.com/post/73791304724/auth-with-json-web-tokens
Discussion on rubygems-org slack which is considering macaroons for *. rubygems.org auth:
> > TL;DR - i want http://rubygems.org|rubygems.org to be an oauth provider for any apps at *.rubygems.org
> > so any satellite apps do'nt need to write their own auth/identity management
> there’s a better alternative but it’s… a bit half-baked :neutral_face:"
> I need to write a blog post about it
> that’d be Macaroons
> also I feel like a terrible punster every time I say Macaroons are half-baked
> this video explains how they can be used in federated identity/authz contexts:
> Honestly either macaroons (or oauth) looks like something that is approachable for beginners to integrate
I'd probably avoid cookies, except maybe session cookies, (make sure they're secure/signed and http-only) and use tokens.
-Benjamin
Hugh Francis
Jun 4, 2015, 12:37:41 PM6/4/15
to rails-a...@googlegroups.com
+1 for ember simple auth
Reply all
Reply to author
Forward
0 new messages