so a question which has been confusing me. I have created a simple API server using ruby on rails and able to read the data through my android program i created. SO I wanted to create a user register/login , however then it struck me i would probably need a token authentication so that not everyone can come and delete my entire database right ? However, now im confused , do i need to have 2 authentication before using the API then ? One for social media such as facebook, twitter , g+ , and one for the API itself ? I know it sounds silly, why would i need two authentication? But i thought i best ask look around first for my answer. Also since i heard facebook authentications token usually expire every 90 days.. does that mean i have to relogin the user every 90 days ? Would be good if someone can point me to the right direction
Have you hear about Firebase? They have quite a lot of examples on how to handle authentication with their services. They can handle your backend easily for you.
Best thing about Firebase is that it is free for low usage apps and the pricing is quite reasonable for a small team.
Here are some useful links.
https://firebase.google.com/docs/auth/
https://firebase.google.com/products/
Related
I've probably spent 150 hours the past two weeks reading up and watching tutorials on mobile app security and authentication strategies for REST APIs, and I've perhaps never been more confused and overwhelmed in my life, lol. I've learned a thousand things I shouldn't do, but I still have no real handle on what I should do.
As background, this mobile app won't be dealing with super sensitive information (no financials, no HIPAA content, etc.), but I still want to secure it and its REST API with best practices, preferably while maintaining my sanity. The API will be private to the app, Python-based, and allow email/password login as well as social login (Google/Facebook). Once users initially register and log in, they should never really have to log in again unless they intentionally log out or want to log in on a second device.
I've looked into both Django Rest Framework and Flask for building the API, and even though the nuts-and-bolts style of the latter seems more to my liking, I've homed in more on DRF since it seems to have better documentation out there with respect to authentication. Among the most helpful guides I've walked through to date are this 2018 Medium article on Guide to an OAuth2 API with Django; and this 2020 YouTube video on Social Logins with React and DRF (using drf-social-oauth2).
However, I'm still left with a ton of questions/concerns:
I've yet to find a guide/tutorial that helps me fully understand how to implement PCKE into the OAuth2 workflow (which seems to be the current recommendation). Is PCKE really standard practice these days, or have I just gone too deep down the security rabbit hole?
With libraries like drf-social-oauth2 and django-allauth + dj-rest-auth, I'm struggling to understand how to separate the authorization server from the resource server (and perhaps a third authentication server, in a PCKE workflow?). It sounds logical enough in theory, but for the life of me I just can't find an understandable model for turning that theory into reality. I'm surprised I don't see more people having the same sort of confusion, so I wonder if I'm just missing something completely basic.
The YouTube tutorial I linked above seemed pretty strong, right up until it started embedding the Client Secrets directly into the (React) app, which everyone (including the guy on the video) seems to agree is a huge no-no. I'm guessing those secrets belong instead in the code on the Authorization Server (well, rather, in the environment variables of the server), but, again, it's not clear to me if libraries like drf-social-oauth2 facilitate such a setup.
Have I been right to focus so much on OAuth2, or should I have been learning more above OpenID Connect (OIDC)?
That's just the start of my confusion. Even once I figure out the above and get my API to successfully grant tokens to my mobile app, a whole new set of questions arise:
Since I want my users to stay continuously logged in, what should my token management strategy be? Should I even bother with refresh tokens, or is there a use case for issuing access tokens with no expiration date?
Is there a strong argument to be made for using JWTs instead?
Is it (relatively) okay to store tokens in shared preferences on an Android app?
If I do rely on refresh tokens, is there a general strategy for how long access and refresh tokens should each last? And how/when in the app workflow should tokens be refreshed? (NOTE: This is the question I've done the least research on so far. I mainly include it here to underscore how lost I've gotten in trying to figure all this out.)
And then the more existential questions:
If I implement this all perfectly, how much am I actually accomplishing? Like, even with client secrets hidden away in an authorization server and PCKE in play and all that, someone who roots a phone and decompiles my code and can mimic user registration and get a token and make API requests, right?
In other words, am I even asking the right questions?
Anyway, apologies for the lengthy confusion of this post. I think I'm probably 70% hoping for answers, 20% looking to vent, and 10% hoping for moral support. It'd be great if someone can maybe at least let me know if I'm on the right track; or point me that direction if I'm not. Thanks!
Is there any chance to bypass Fb messenger by getting reminders/event/alarm information being set on a group chat. I am planning to create an algorithm or an app that automatically saves a reminders/event/alarm so that later your phone will alarm even in offline. Thank you in advance.
Well your question is quite broad.
By the way, if you're searching some way to get facebook events, alarms and reminders I suggest you to take a look to their Graph API.
You can see here to get started with the Android SDK.
You can query Facebook for all the information you need through the API, and then do your thing.
Disclaimer: I have no experience with this API, this is why I couldn't get you more help.
I just pointed you what I thought you are needing.
I hope that this is what you're looking for!
I want users to send textual feedback to myself(the developer) directly(without involving Google Play).
Hence, I can get the suggestions to improve my app directly to myself, instead of users writing negative reviews on Google Play.
I do not own a website nor have access to any server.
I do not want to use ACTION_SEND, as that opens an email app.
I'm an android beginner and this is my first app.
Maybe that data can be stored in a database(on cloud, common to all users) that I can access at any time I want?
After researching, I think GCM is supposed to be used, but I no idea how to go about it.
Please tell me the easiest way to implement this.
Thank You.
That is not what exactly what GCM is for. GCM is primarily for sending data from the cloud to the the devices.
You are correct in thinking that one option is to store the data in a database in the cloud. You could use http://pythonanywhere.com free account and build a web app that provides you endpoints which will save and retrieve data to a SQLite db pretty easily (if you have knowledge of python and server side web concepts).
Another perhaps simpler option is to use a pre-existing cloud database solution http://www.parse.com is a cloud backend that also has a free-to-use option that you can use to store arbitrary data. It is pretty easy to get up and running if you follow their many nice Android tutorials.
One last option I will present is to use a Google Spreadsheet with a Form associated to it. Once you create a form if you know the right url and parameters you can send a post request to insert arbitrary data into your spreadsheet. I've created a library that simplifies the process of uploading. GoogleFormUploader. If you need help getting your form set up you can watch the relevant portion of my video tutorial covering this topic
I'm considering using the Parse cloud data service for my iOS/Android mobile app.
From what I can see from the documentation, my app would be highly coupled to the Parse SDK, which in turn uses the Parse REST API (I assume).
What measures can be taken to redirect the app to another service if Parse is down or if I no longer want to use Parse?
Ideally I would like to be tell the Parse SDK to use my own domain and redirect it to the Parse servers (how?). If Parse fails, I can change my DNS to somewhere else and attempt to replicate the Parse REST API (how?). Is this possible now? Is there a better way of preparing for this scenario?
parse.com seems to be down right now and I was just searching randomly online and found this post. Given I can't work on my project now due to the outage, I will put in my 2 cents for this topic.
First of all, I am definitely not happy if my underlying service provider goes down, no matter that's parse.com, AWS, rackspace or something else. However, that's exactly the trade off we signed up for and in return we enjoyed the ease of development and shorten our development cycle from 1 year to something like a couple of months.
It's dangerous for early stage startups to spend too much time and energy focusing on issues that are not the most important at the given point of time. Personally, I will not worry about parse.com being down as long as I cannot afford the time and resources to build and maintain my own database cluster. Obviously, it's under the assumption that parse.com will still be up for most of the time, something like 99.9% :)
The Parse support and sales team got in touch with me about this. Unfortunately they opted not to have a public discussion so I will paraphrase what they told me.
It is not currently possible to change the server url of the SDK. They're not sure if this is a feature they want or not. (It should be noted that the server url is exposed in the JavaScript SDK and can be easily changed; search for api.parse.com.)
Using Cloud Code, you can build your own server API on top of Parse. The Parse SDK has a PFCloud that can be used to talk with Cloud Code but I couldn't find any usage examples in the documentation yet. This is similar to what toadzki's answer, but should be much simpler to implement.
They also offer custom server installations of Parse.
To take the opposite view...
How big is your app and company? If you're a lone ranger or a small outfit working on a smallish to medium app, the answer most likely is "Don't bother". Yes, in theory you could set up a system so that your app (or some infrastructure somewhere) redirects to a different cloud service, but the time and effort taken to do this, and do it well, is significant. Consider that even if you think you've implemented such a system, you're then going to have to test that it works. Not really a simple task.
Mirroring the Parse API and then forwarding sounds simple, but the devil is in the detail. Especially for something like this.
Also, adding your own forwarding server is going to add a point of failure that will almost certainly be the weakest link in the chain. In short, don't bother!
As an alternative solution to toadzky solution you could make an interface to all parse methods on the device so you easily could switch Parse sdk out with your own custom implementation. In short make wrappers for all parse calls.
That said parse is very reliable and a lot of the functionality also works in offline mode. Also you'll get error responses which you can handle in whatever way you see fit.
If you want to route requests through your own server, do it. Have your server run the Parse SDK, not the device. Make your requests through your own custom API and repackage the request and forward it to Parse. This way, if you decide to change cloud providers, your app can still work without an update.
Hello I am creating an app for phonegap on android and I wanted to see how I can make a user login section. This section should let them register with a username and password and enter their email or just login if they already have a username . Also do I need a website to hold all of this data?
Thanks!
you need to try things before coming to SO.
BUT to point you in the right direction.
1) create a simple restFUL API that lets people sign up
2) use Local storage to store that info on the users phone
3) each time the app launches, do an ajax request to your server with the localstorage username and password
4) Let user do what ever.
It's really quite a simple process - as for your hosting question depending on what you see usage being... if your app is going to be getting a lot of traffic you should consider a cloud based solution. Amazon will let you quickly scale the app and automatically take care of load balancing, Heroku is also pretty good at this. On the fly scaling as well.. Lastly getting a host like Bluehost is a good option - flexibility, and reliability - also a good price.