I have an existing rails application where the users can register, login and do a few activities. Now I want this to be done through an api so that this it could be used from some kind of external app like for an ios or android application.
I have doubts on how to approach this. I have before created versioned apis and also secured them with the technique of uuids for each user. But here, I already have validations for the user model which validates his email, password and stuffs. I dont think that would be a rightful approach when it comes to the api, specially for a mobile app user to be entering a password to register is not the common practise I think. If some one could suggest an idea where the api could be integrated with the existing application logic and let me know how to bypass these validations, it would be of great help.
Related
I am using rails 4 and developing my first API. The API will be used solely for our android and ios apps to communicate with the rails app / database.
I am struggling to see the difference between API authentication and user authentication when it comes to an API. It seems people use these terms interchangeably.
I want my api to be secure, meaning only the apps can submit http requests, but I also want users to be able to log in. And when I say users, I mean app users... not outside clients who are accessing our api (we don't want this at all).
Would love if someone could clear this up for me. I may just not be thinking about it in the right way, therefore confusing myself.
So to break it down, these are the two things I need to be able to do:
secure the api of course... making it so only the mobile apps can access it
users are able to log in and access their profile, resources that belongs_to to them, etc. When users aren't logged in, they still need to be able to see the index and other pages that don't require a logged in user.
thx!
Have you heard of JWT? It's a good option to hadle users with the app and rails api separated.
Gem for jwt in rails: https://github.com/nsarno/knock
I've been using Firebase as a way to synchronize data between a Rails application and a mobile web-kit based application. I've recently been attempting to use the email/password authentication method in lieu of custom auth tokens.
Everything works as expected, but my concern is with user creation and authentication.
Currently, I'm able to create a user, both on Rails (using a self-modified version of the firebase-ruby gem) and through the mobile app, using the firebase node module.
So from the stance of a malicious user, is it correct to assume that I can create a Simple Login user with the JS library (for anyone's firebase instance), and then authenticate with that user, and attempt to read any data that they have stored?
Of course one shouldn't leave their entire Firebase data structure unprotected. So this only works in a situation where one has only set up the default security rules.
Either way, is there any way to prevent anyone from creating users, except for myself (or some other authorized person) without resorting back to custom authentication? I understand the difference between authentication (the server knows who you are) and authorization (the server is letting you in).
Any feedback is appreciated.
In my conversation with Frank, it appears that there is no way to prevent malicious users from creating any number of accounts on a Firebase instance through email/password Simple Login. This doesn't allow them authorization to any data per se, but could be annoying for the SysAdmin/DevOp who was maintaining the Firebase instance.
I have two Rails apps, and I would like to accept user login credentials from one app (say App A) in another (say App B). For the app that's accepting login credentials (App B), I think the best option is to use OAuth. But for the app whose user credentials are being used (App A), how do I allow the user's login information to be used by another site? Do I use OAuth as well, or something like Doorkeeper? As you can tell, I'm very new to user authentication, so any advice would be helpful!
One possible way to solve the problem is to create a doorkeeper-based standalone app that would contain all of a user's credentials. Then your client apps would actually connect with this "auth app" (using Oauth.) Then when the client is authenticated on the Auth App, they get returned to the Client app. Of course, from a UI perspective, you make this seamless, so your login page would actually be on this Auth app, but it would look seamless to the user. This way, you can add as many apps as you want and the credentials would all be in one place. To answer your specific question, you would use Oauth2 on your Client apps and Doorkeeper on your Auth App.
You'll need to tweak the doorkeeper configurations to make this process "clean" to the user. For example for internal apps, you can safely use the skip_authorization method in doorkeeper. Learn more about that here
This doorkeeper/oauth system has the added benefit of decoupling your authentication logic from your main application, which is fundamental to good Service Oriented Design. There are certainly other ways to approach this problem, but given the context of your question, yes, Doorkeeper and Oauth2 would solve your problem.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.
I have a web app that needs to provide lightweight user access to a mobile client, via an server side API.
These users need to be authenticated, but do not need to ever login to the web app itself.
Instead of creating a traditional User model, with authentication/authorization, I am thinking of instead creating api keys that get emailed to the relevant user email, so they can just use that to access the mobile app.
Has anyone used this approach before?
I know you shouldn't send access credentials via email. But I can't think of another way without going for the full blown User model approach, which is overkill here, in my opinion.
Thoughts on a postcard please.