Is there a way to setup auth without password where user receives one-time password on every login.
Only auth option for Rails that I know of is Devise but it doesn't seem to support "passwordless" auth.
Are there any other options and am I missing something about devise not supporting it?
You could consider requiring your user to have a Fido U2F compliant device.
They need to plug it in on register. and on login. It is more commonly used as 2nd factor authentication. but I can imagine people who might want to use it as a single authentication method. The protocol is web_authn and there is a gem for it in ruby.
https://github.com/cedarcode/webauthn-ruby
you can test at https://webauthn.io/
you could also consider the more common OTP Authenticator app.
Have people scan your QR Core on signup, and that would become the only auth required.
is this what you are asking? Single method of authentication, without a saved password.
sent everything by email or SMS seems annoying
but that is also possible.
Related
My use case is something like this.
I'm developing a rest api and single page web application.
But I don't want to store my user credentials (email, password) with me.
I want to store it in more secure place. From that place I need to verify credentials and issue tokens, as well as first time user register with the system that user's email ID should be verified and also If an user forgot his password there should be a way to reset it as well.
Finally in my node.js back-end I need to protect my routes from unauthorized accesses.
Do I can achieve all this things using a authentication service provider.
I go through the firebase docs and found It is little bit harder to implement my what I want using the firebase.
Is authentication services capable to provide reset password and email verification and store user credentials.
Or it just a token generator only?
If you are asking if Firebase Auth provides the ability to generate tokens for verified email/pass credentials it securely stores with email verification and password reset, the answer is yes. Learn more from their official documentation: https://firebase.google.com/docs/auth/web/password-auth
They also provide the ability to issue session cookies better suited for a Node.js server side managed sessions: https://firebase.google.com/docs/auth/admin/manage-cookies
You don't need to store the credentials. Firebase Auth will store them for you using industry best practices.
I want to build a backend API with rails-api. In addition, like StackMob, I want to build my API based on OAuth. Thus I think I should use doorkeeper too.
However I am not sure how to write user signup, login and logout part.
First of all, in the rails-api, there is no session, thus I cannot store logged in user_id in rails' session dictionary.
I guess I should do like this: when a user tries to log in, I first check the database to fetch such user, then generate an access_token using doorkeeper. Then I return the access_token to client. Afterwards, when the user tries to get some resources, I use doorkeeper's authentication (i.e. OAuth) to check authorization.
Is such way appropriate? Could Anyone provide any advise?
BTW, I tried to use devise for user loging in and out, but it turns out that devise is not suitable for an API app, at least I cannot handle. Any help about Devise is also welcomed!
I use rails as backend for ios applications. So far i have been using devise as it looks flexible and comfortable to use with less effort . And i have read about omniauth and that too looks easy to integrate with devise. My question is, consider my ios app requires authentication and the following are the different methods that i should be able to allow user to do
Login using email and password
Login using Facebook account
Login using Twitter account
Login using email can be handled by the devise itself but how about login using Facebook and twitter? Actually in one of my project i came up with the following approach which has all three of these login process. The ios app authenticates the user from the device(not devise) itself and sends the user information like username, email etc whatever required along with auth type so i save this a separate user with username that is sent and one of the field as password. And the next time he sends me these details i allow him to login to the app. But now i realised this is not the best way to do. I read about FBgraph which can be used to verify the access token validity, so should i get the token from user and then verify it and get the profile information and save it in user model and give them the token.
Also i have another doubt which is, For login using email and password i allow user to login through email and password and then for the each requests the user sends me the username and password. Is this is alright or do i have to create a token in login request and send the token as response and then the user can send the token for all the other request he makes.
Sorry if it is confusing but to tell you shortly i need to know what should i do if i have all these three login process. Any help is greatly appreciated. Thankyou
There are couple things to consider when dealing with external applications like on other devices:
You should use an API to communicate with your Rails server
Your server should send an authentication token after the first user authentication using his email and password. It is not a good idea to send user's email and password for each requests.
Devise
Devise is great for authentication both in-app and for remote applications using the token_authenticatable hook. This will allow any registered user to have a unique secret token to use in order to be authenticated on your server.
More information here
OAuth2
OAuth2 is becoming the standard way to authenticate on remote services giving the user the possibility to use his Facebook account to login for example.
This would be the easier way to allow your users to authenticate using their Facebook or Twitter account (note that twitter will not give you the user's email address).
Devise can handle OAuth2 clients.
Finally, you could also create your own OAuth consumer to authenticate users using your service. Doorkeeper is a great gem to protect your API endpoints and to allow users to use OAuth2.
Conclusion
Devise is great for authentication. Using their token module coupled with OAuth2 integration could do the trick in your case.
Here is the OmniAuth wiki page from Devise
Here is the Simple Token Authentication wiki page from Devise
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.)
I have a rails application, and I authenticate users to the application using Devise.
The question is that I'm building an Android application and I want to understand how is the flow of authenticating users on the android "the easy way". I read about Basic and Digest Auth.
or the api I use Grape https://github.com/intridea/grape which has Basic and Digest middleware for authentication.
Am just wondering should I have store email/password of user on the android app?
and each request to the api should attach the email/password of the user?
Also, whats my benefits of the auth headers in the authenticated response?
I would highly recommend NOT storing the password anywhere, and storing the username is also most likely unnecessary. Instead, look into the token_authenticatable feature in Devise shown in this blog example. What I would recommend doing is when the Android app user enters his/her username & password combo, you call a custom token authentication sign_in controller with what the user entered and return the token to the app. Then you can store the token in your app without worrying that the username/password may be compromised.
This gives you the flexibility for how frequently you want to regenerate the token, or to invalidate a token arbitrarily.