We are developing Native Mobile Application : Android platform, Ios Platform (Swift).
Instead of asking user to download and install https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en_IN mobile app and then generate a QR code in our application to be scanned by this app, we are willing to do it api way. Means We want to call Google Authenticator API pass it QR image, secret and user is registered
Is this Ok and possible. Any one using it please suggest.
I'm not going to say that this is impossible, but integrating Google Authenticator would be a nightmare, and likely wouldn't do what you're expecting it to do. Allow me to explain.
Problem #1
For each instance of the app, you'll have to have a Unique Identifier to pair it to Google's Authenticator. In other words, you'll need to generate a new QR code for each device, pass that off to the system (Which doesn't exist without the app.) to pair the application. This is going to require a "Log-In" to properly store.
Check out this for a possible work-around to Problem #1: https://authenticatorapi.com/
Problem #2
If you're already logging in and the device is already being authenticated, what purpose does the Google Authenticator provide? Well, I'm assuming it allows you to prevent unauthorized access, possibly prevent more than one device. There are infinitely easier ways to manage this, location services are the first one that comes to mind for me.
Possible Solution (iOS)
This is absolutely my go-to method for handling authentication. Encourage or require your users to use 2FA (Two Factor Authentication) attached to SMS messaging. A simple line of code such as this will grab an SMS one-time code.
// Available as of iOS 12, make sure to check version.
self.verifyCodeTextField.textContentType = .oneTimeCode
Android SMS Retrieval
Android Auto-SMS-Retrieval https://developers.google.com/identity/sms-retriever/overview
I don't know it all, most certainly, but I hope this opens the floor for some discussion and brings forth a solution or explanation to your question.
Research Material
Google Authenticator available as a public service?
java API for google Authenticator
Related
Illustration:
How do I pass data coming from a form in my app to a third-party app?
Also, what are the terms, functions and APIs about doing this?
It is possible through Intent and URI.
The app that is receiving your data should support be open to receive URI so that you can fire up the Intent method it will open the app and send data.
You can refer: https://developer.android.com/training/basics/intents/sending.html#java
Unfortunately there is not a one-size-fits-all solution to this question, as such you are going to receive a variety of different "solutions" but the truthful answer is, it depends on the implementation of the app built by the other party;
Intents
If the third-party app is open to receiving data through intents, and hopefully the developer of that app has documented this somewhere. This would be the most streamlined approach.
It is important to note with this implementation that if there are specific apps you have in mind to connect to, and your application is going to be publicly available, then the user will need to have those specific third-party apps installed. This is easier if you only have one specific third-party app in mind (you can check the user's device to see if it is installed and inform them), and gets exponentially more cumbersome for every additional application you wish to connect to, not only due to having to instruct the user about yet another required third-party app but also as you will need to make sure you are able to pass all the necessary data to a completely different application.
Have a look at this earlier question to see how this can be achieved.
APIs
Another solution would be to use APIs. Just like intents, this requires the third-party developer to have exposed their application to these specific API calls, which you can then connect to to pass your data. The simplest real-world implementation of this approach would be signing on to an application using a social media account instead of having to create a separate account per application.
This is less streamlined than the intents approach as it would involve additional steps of posting your data to the API and then opening the other app in order to retrieve the data and proceed.
I have a full application API written in node.js with Express.. Now, the API should be only accessed from my Android application, how can I protect the node app from outside requests?
If I use some kind of a password protection, I'll have to write that password in my android app and since the application is available to everyone, the password can be easily found.. What is the solution to this kind of situations?
Web based security can be a bit tricky sometimes, but if you have an app you could use a token-base approach.
When your application starts, it can request a token from your API, which then must be present in all other requests to your API.
Did a quick search for this kind of thing and came upon this page, which might be worth a look: http://thejackalofjavascript.com/architecting-a-restful-node-js-app/
I'm busy building an app for android. When it's properly received by Android users I would like to expand to iOS.
But, before we get there, I first want to make the right choice. So my question, what to do?:
writing all the logic inside the app and use Cognito (https://blogs.aws.amazon.com/security/post/Tx3LP54JOGBE0AY/Building-an-App-using-Amazon-Cognito-and-an-OpenID-Connect-Identity-Provider) to access the data from DynamoDB
or let my app connect with my own API which handles the validation rules, which I then connect with DynamoDB database (don't know or API -> Cognito -> DynamoDB is a better solution, didn't really used it yet so...).
Now we all know about those issues where hackers built ways to bypass certain validation rules (as far as I read, most commonly by decompiling the app). I really want to avoid that!
So what do you experienced Android developers use? I know the answer seems obvious. But the reason I ask this is because I would like to avoid having my infrastructure, which I need to update etc. But to be able to register users, without the need of an third party which supports OpenID like twitter, facebook or Google, AND secure my validation rules, it seems like I have no choice. Or do I?
If you are targeting multiple platforms, it's usually best to conduct the majority of your business logic in an api outside of the app. It reduces code duplication and if validation is done at the api level, it limits the ability of malicious users to bypass validation rules.
With that said, running your own api doesn't necessarily require running your own infrastructure. Two AWS web services that could help are Amazon API Gateway and AWS Lambda. Registering your users can be done using Amazon Cognito Your User Pools.
I have a public REST API that I want to protect. I've read about HTTP basic authentication, OAuth, APIs Key ... but as far as I know, this methods require registration (username and password). I want that the users (Android apps) of my service can use it without registration and login.
So, ideally, I want that only Android apps can use the service and I would like to control the usage of the service. I've thought about get something unique about Android devices but I think it is easily falsificable.
The reason for no registration is that the service is very simple (check out the bus arrivals, and participate sending some time arrivals) and I think is overkill that users have to provide a username/password for such a simple service.
How I can achieve this?
I want that only Android apps can use the service... How I can achieve this?
You can't.
You can try to casually reduce the number of things other than Android apps that can use your service (e.g., have your app use a custom user agent header in the HTTP requests, and use SSL). However, people who are determined to get past that will be able to do so, by reverse-engineering your app, or sniffing on the HTTP traffic.
If I am building an Android app that uses the Facebook SDK and also has a web app that has most of the same functionality, how should the Android app handle social actions? Should it directly make requests to the Facebook API through the SDK or should it post to the web app server through my own API and allow the web-app to make the request to Facebook on behalf of the Android app? Most of the Facebook for Android examples use the former approach however none explicitly discuss the best practice when there is a web backend that will have the same social functionality as the Android app.
I've been putting my mind into a similar problem before. It was a PHP app, but essentially the design choice was to either put the FB-interaction into the frontend (JS-SDK) or into the backend and proxy it (PHP-SDK). Sadly haven't found much guidance either, so I had to make up my own mind.
As so often there seems no per-se answer, it depends on what you are doing with FB and how deep it is integrated into whatever your app/webapp/backend are doing. Is your Android otherwise more a client-side app or does it rely on other features delivered by the web-app via web-service? Is it somehow integrated with users actions that are dispatched to the backend, or does it just offer some additional gimmicks (e.g. 'Like' button, anything in the lines) Are you using the SDK to authenticate and pull user related data from FB (email, name) and does that information play a role in your backend?
As I see it, it boils down to the following:
Direct communication with FB is a lot simpler to implement as you won't have an additional layer between your app and FB, i.e. proxy code, etc. So if FB is just loosely coupled it's likely the 'good-enough' option.
Patching FB from frontend to backend can get nasty - especially if you want to authenticate via FB it's kinda complex at first. However, you'll have all FB logic in a single place, shared by Android-App and Webapp, so it's obviously easier to maintain later and better to integrate with other interactions your backend might be offering.
Hope that provides some value, would be eager to see other opinions too.
Well I think both approaches are correct but the choice depends on mostly what you already have in place on the server side and if you are planing to use the same functionality from different apps like (Android,iOS, Windows Phone apps). In that case it makes sense to just get user token with permissions you require on the front end and let the web server talk to facebook using that token. You could even save this token for the user so they don't have to give permissions again if for example you have web registration and app registration. In our app we are using this approach since there are basically five front ends (Android,iOS, Desktop,Mobile Web,Full Web) this way application developers just get token using sdk on there platform (you have to use tokens and not user name, password because of facebook rules for security). On the other hand if all Facebook communication is used only inside your app and the server doesn't need to know much about it put api calls in the app.
In my opinion, it is best to use the available SDKs/APIs for each given platform instead of trying to write your own centralization and use a single library. Since you are specifically interested in how the Android app should handle social interactions, I suggest using the Facebook SDK for Android.
While it does increase the size of the code you must maintain and the SDKs/APIs you must learn as your list of platforms increases, the most important factor for this approach is the user experience. By sticking with the native libraries, and growing your app as those libraries evolve, you will be providing your users with an experience that they are most likely to be used to. They won't have to learn how to use your app, but will be able to make posts, update their status, and look at their friend list using controls that they are accustomed to using. Additionally, you will be able to take advantage of specific platform functionality (in the mobile case, such as having your app post to a users feed in a way that promotes your app: https://developers.facebook.com/docs/tutorials/androidsdk/3.0/games/feed/)