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
Related
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.
Recently I just notice how Path, Pinterest, and the like change the way they authenticate their users. Currently it seems that they require us to create an account associated with Facebook or Twitter. I could not understand the reason behind this. Is there any security concern for them to make this move?
Why is simple authentication with Facebook and Twitter not enough?
I think it is about giving the site more control over their future and the relationship to their users.
If they have their own account system, but allow the users to link it to Facebook or Twitter, that link can later be changed if the relationship with those providers turns sour.
The big reason is that they don't have to take any risk with handling passwords, etc. which can get hacked. They are offloading the security of user accounts to bigger partners, so they don't have to worry about it.
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'm working on a school project. We are going to make a bug/rodent themed tower defense game. The game will primarily be an Android app. There will also be (at least we want there to be) a Ruby on Rails website/application tied together with it.
One of the requirements for the project is to implement three levels of user that will interact with the project. We decided that the three types of users will be administrators, guest players, and players with accounts. Players with accounts will be able to accumulate perks. Guest players will be able to play, but won't have any capacity to earn perks over time. The administrators will be able to manage the users with accounts (delete, edit, et cetera) via a web browser and the Rails application.
I want the users with accounts to be able to login to the Rails application via the Android app. There will be parts of the game that only users with accounts will be able to access. How can we create a login/logout scheme for the Android app? I'm thinking it will be something like the user enters their username/password, taps login, and then the Android app will send a request to the Rails side. Once the user is logged in via the Android app, they can access certain parts of the Android app that guest users cannot.
How would I go about this? I'm not sure where to start.
Would the Android app, using Java, send http requests to the Rails application (sending the username and password)? Then would the Rails application send back some sort of success? How would the Android app hold onto this successful login like a session in a web browser? Also, the Android app will need to update user attributes in the Rails database (something like accumulated perks).
Is this possible?
I've seen miscellaneous information about how to do this scattered online in blogs, on stackoverflow, and on discussion boards. But, I haven't found a coherent solution for my group's needs.
Thanks.
You can use your rails apps as an oauth provider (https://github.com/pelle/oauth-plugin) and use an oauth client library on the mobile application
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.