You’re not receiving notifications from this thread.
Is it necessary to use authentication with an API if there aren't really any 'users'?
I'm writing a React Native app that is purely informational (medical information), with a Rails API for the back-end.
The first main question I have is whether its necessary (or a good idea) to use authentication at all. We don't want the user to have to enter any information to use it (username, password, etc). They should just be able to download the app and jump right in to use it and read the information it provides.
However, I'm thinking that I would at least want the API to only respond to someone hitting it from within the React Native app (or not? Is it considered a normal practice to have an API completly exposed in the case of an app like this which is purely information and doesn't have users, like a website?)
Second - at some point we may want to be able to store some simple preferences for that user (I.E., are they a patient or a doctor, so we can tailor the materials based on that / send them to a different home screen when the open the app). I'd guess that simple preferences like that could just be stored locally on the app, and wouldn't be a strong enough use case to make users? Obviously if they re-downloaded the app, they'd have to rechoose...but that would be fine.
That's a great question. I don't see any need for authentication.
I mean, worst case if someone started abusing your API, you could do some simple checking to make sure the requests came from your mobile app by verifying a user agent header specific to your app. If your API runs on SSL, then those headers should be encrypted so that no one could sniff that user agent to apply to their own requests. Same sort of thing could be done by doing a basic auth requirement for your app and hardcoding the password inside the app. Those are both probably findable if someone disassembling the app, but you'd really just want to prevent any basic abuse if that ever became a problem. Rack-attack's a useful gem to prevent too many requests from hosts as well that could be useful to keep in mind.
Most of this is all unlikely to be needed and you could roll out changes for this stuff later on too if it became a problem. Probably not something you really need to worry about too much, just like you don't worry that much about it when you're building a public website until abuse becomes a problem.
And since there's no real need to have accounts, storing preferences on the device makes perfect sense. There is a unique device ID for each phone, so you could send that over to be the identifier for storing preferences server-side if you really did need to restore preferences after a reinstall.
Great ideas with the user agent/password. I highly doubt someone would disassemble this app in order to spam the API.
Rack-attack looks great if I ever need it. Good to know in general for any Rails app.
I totally agree with your thinking on 'deal with it later if it becomes a problem'.
Really I do not need authentication. That is where I was leaning but I wanted to be sure.