Currently I have two servers set up, each handling there own thing, but I want to have a unified login between them. Right now one portal's login form is simply sending the username/pass through an API to the Rails portal, and it sends back an auth token, which we then store in our session and use for future authentication and API calls.
So the problem becomes that a user visiting our site has to login once in each portal, since the Ruby API doesn't communicate with ours, and the Ruby side doesn't do anything with the session when the API is pinged but send us back and auth token.
My initial idea was to have the Rails side create the session when we send the credentials to the API, but apparently that won't work as they won't be able to set the session id in the users browser, or at least that's what I was told.
If the Ruby side moved over to using the database for session storage, would that alleviate this issue? Basically, I want to keep most of the changes on the Ruby side for this.
I have implemented session sharing using memcache concept between Ruby on rails and PHP. i got success in this. if you are familier with memcache concept then it will be useful for you. and if you need any help for the same then i can share with you.
We wound up going a slightly different route. Basically, each side looks for the auth token in the database, and we pass it around via query strings on each link to the other. For example, if the user logs in on the PHP side, the Ruby side receives the username and password via the API, creates an auth token and updates the database, then sends back the token. The PHP side then stores that token in the session and sends it back via query strings (?authToken=blahblah) to the Ruby side, which is always listening for them. If it sees the auth token, it checks the database to make sure there's a match, and if there is, the user is authenticated in the Rails session.
Conversely, the Ruby side's login form simply updates the auth token in the database, and the links that point to the PHP side also pass the auth token. That side does the same check and will authenticate in the case that there is a match.
Related
Trying to wrap my head around some logic.
I'm creating a simple turn-based game with Node.js and Socket.io. The idea is that each user 'logs' in via some framework front-end system (quick RubyOnRails scaffold) and then once they are logged in, they can refresh the page and close the browser and they remain logged in as usual until they log out.
I want this functionality of persisted authentication with a web socket so that while 'in-game' users can close their browser and come back at any point and I can relay to other users when a player is disconnected/connected. A player could also join and leave games but could obviously only be in one at a time.
My guess is that upon each page load the new socket.id that a user connects with is needing to be stored in the database inside the users table perhaps? Or is there a simpler way to tie a current user to a socket.id?
Am I going about this the wrong way? I can't seem to find any good examples/documentation similar to what I want. Some code examples or a starter app to push me in the right direction to achieve the basic idea of what I am trying to accomplish would be amazing.
You can make use of tokens for this purpose. A good option would be using JSON Web Tokens (JWT).
JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.
- https://jwt.io
One possible way to use JWTs in your case goes like this:
User logs in
A new JWT is issued by server when a successful login happens
This JWT is sent to the client and is stored client side (e.g. cookies, local storage, etc.)
On every socket connection event, client sends this token to the server for validation
Server accepts connection only if the provided token is validated and closes the connection otherwise
The main advantage of using JWTs is that there is no need to store additional data server side because tokens can be validated using cryptographic methods such as digital signatures.
More on JWTs: https://jwt.io
I am building an API for my rails app. Through that API I will log users in and allow them to interact with their data.
On top of that users authentication, I will also like to make sure only my iOS app has access to the API, and eventually my own web app.
I want to make sure no one else will be using the API, so on top of the user authentication, I will like to protect my API with a token for each of my apps.
How do you usually solve this problem? Would I have to pass that token over on each call in order to authenticate that the call is coming from a valid client and identify which client it is (web vs iOS).
I will very much appreciate any pointers or if you know of an article explaining how to deal with this.
As you are already using jwt's to authenticate your user, why not just use the functionality of jwt to include additional information in the token, in this instance some form of hashed string that you can verify server side if it is a valid "client id".
On each request you could refresh the string.
Kind of dual authentication in each request. the user and the client.
I am working with an Arduino that I want to send data to a remote or local Rails RESTful API of mine. When building its front-end, I can login with devise and authenticate. But I am wondering what happens when you want a third party device to POST data to the backend ?
One choice could be to use random generated long hashes as keys, as Twitter does (a client key for example and an API key) which of course is not secure but decreases the chances someone will POST data easily to another account.
However, If I am right, the data will be sent over an http connection so they could be easily sniffed. There is no problem sending temperature data, but If someone decides to send RFID IDs and names etc. it could be a vulnerability.
How could I send data with a POST request to a RESTful Rails backend API:
authenticated?
secured?
authenticaed?
You will need an endpoint that the 3rd party can call (let's call him Zed). Zed sends a request (POST) to that endpoint with his email address. Devise then sends an email to Zed, with a confirmation link that contains a confirm_token. Zed clicks the link, which opens a page where he can enter a password. Once entered, he is logged in and an auth_token is stored against his user id. Subsequently he can use that auth_token to make further requests by passing the token in an Authorization header. The 'confirm_token' is throw away (you can set it to auto-expire after a given time period).
Obviously this requires Zed to manually create his account and login. Even if you setup a 3rd party 'developer program' you still need those developers to sign-up and generate tokens for them that they can pass in requests to your api. All of this should of course be done over https. Devise provides almost all of this capability out of the box.
secured?
HTTPS helps with the 'sniffing' aspect. The method above is secure, since only people who provide an email account they have access to can create accounts and get tokens that they can then user for later requests. However, you could use mobile phone number/sms as a second factor (google 2-factor authentication).
Without authenticaion - well, sort of
The only other option I can think of is that you issue known users a 'signing key'. They sign (encrypt) their request with this key. Since the key should only be known to them and can only be decrypted by the server using the matching public key, the data can be sent over HTTP. If anyone sniffs it, they almost certainly cannot crack the key to see what the real data is. All they can really do is mimic the request and keep sending that same request to the server repeatedly in a DOS attack.
But you still have to solve the problem of how do you verify WHO you are giving keys to - ie you still need to verify who Zed is somehow. Do you plan to do that offline and then email that 'verified' individual their private key? Using RoR, I still recommend sticking with Devise as most of the grunt work is done for you already.
I have a Single Page Application in AngularJS with API in Ruby on Rails (Grape framework).
My authentication system looks like this:
User create an account. Sends information to server.
Server save user in database and generate token with Devise. Token and user information is send to Angular.
Angular save token and user info in storage (angular-storage) and token is added to every request (Authorization header).
When user click log out button, storage is cleared and token is deleted in database.
My question is: it this secure, or do I need to use something like JWT? Can I send a role name (for example 'moderator') to Angular without any encoding this? (of course server will always check, if this user with this token can do something)
I also will implement doorkeeper to my app in near future.
I read about token based authentication and get the general id. What I don't understand is why on the frontend (ember in my case) I would need such a token if all communication is with your own restful api backend (rails in my case). If you communicate strictly with your own backend, and you leave the authentication in that backend then why do you need the token in your ember app?
Your backend would serve as a proxy sometimes but is that bad? Is it better to do it directly from the ember app if possible?
I would (mainly) go to twitter for queries.
Thanks for sharing your ideas.
I'm a bit new to this topic myself, but your question is also a bit unclear. If you mean the consumer key tokens that are used in oAuth systems, these are required to ensure that the third-party using your API has actually been granted access to use it - anyone without a consumer key cannot use your API.
Alternatively, if you are referring to users being authenticated using an authentication token...
When you create a rails app that has authentication (for example using the devise gem) a sessions controller is also created/used. Sessions(/cookies) are basically a way of 'remembering' that the user has logged in. This avoids having to resend username/password with every action the user performs in order to authenticate him/her for that action.
This approach works perfectly fine when it comes to web apps because all browsers support cookies. However, this is not true when it comes to mobile apps. It is not possible to keep a session/cookies when using a native app (well it is technically possible, but from what I've read it seems to require quite a bit of manual labor and a bit of code wizardry to get it working correctly).
Now, when you create an API for your app, you need to bear in mind that your API may be used for creating a mobile app (either by you in the future or if you open it to the public). This means that using sessions probably isn't a good idea. For each request that requires authorization the username/password will need to be sent to ensure the user has access to perform the requested action. But sending username/password with each request is definitely a bad idea. That's where token authentication comes in. If you've ever used devise, you will notice there is an option to enable token authentication. This basically allows the 3rd party to send a token rather than the username/password and works just the same. The good thing about this approach is that even if a token gets stolen they can expire and a new one can be generated without the user even realising and without the users password being stolen.
(I'm fairly new to the topic myself, from what I've gathered so far that seems to be how things work. Now if I have made any mistakes in my explanation/understanding I hope people will jump in an correct me.)