Say we have an ongoing token number for queue which is to be shared(shown) among various users who have downloaded that particular app.
Question is:
Where should that common/shared token number be stored? Also which database should be used?
Does this require server setup? If yes, is there any alternative to that?
And how to make that token number accessible to various users of that app?
You will likely need a server to deal with that.
If I were you I would work with Google Cloud. You can very easily integrate App Engine / Endpoints into your Android Apps if you use Android Studio.
Use Google Cloud Datastore
Use Google Endpoints
Share the token through an API of some description - any updates to users can be made real time using Cloud Messaging
Related
This is a question of architecture. What I tried yet: Research, research, research.
I want to deploy various microservices with AWS Lambda. These should be accessible for authenticated users via Web and Android App.
Question 1: How to securely store AWS Gateway API keys (secrets) in an Android Kotlin / Webview app? Is Android Keystore the right (secure) answer?
Question 2: What's the best, secure way to make user login happen? Should the login be located at Lambda or inside the app? Again, how to securely store login data on Android? Could a cookie-based Web-Authentication be the answer (aka "Keep me logged in")?
The goal / my issue is that I want the Android App user to enter his / her login data only once in the App and never be asked again for login at my Lambda Microservices. I'm aware that API Credentials and Login are two different problems here.
Example projects maybe?
This is not for critical data like banking, but still I want to follow best practices as much as I can in terms of sec.
I am not sure whether you have researched on Amazon Cognito or not but it can be used to provide authentication for both user interfaces and for APIs. It can easily be integrated with Lambda/API gateway.
As an alternative to using IAM roles and policies or Lambda
authorizers (formerly known as custom authorizers), you can use an
Amazon Cognito user pool to control who can access your API in Amazon
API Gateway.
Further reading :
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
If it helps I have some cloud demo sample UIs that connect to lambdas and use Cognito. You can run them starting here: https://authguidance.com/home/code-samples-quickstart/
The blog has some write ups on how it all fits together - see the index page for further details - there is a post on UI token storage for example.
Long lasting sessions can be managed via refresh tokens - but your apps should still deal with token and session expiry - and scenarios such as logging on as a different user for testing.
Im currently building an app, back-end and front-end and I use Firebase for saving pictures that the users can upload and download, up till now I've been uploading them from the front-end and if the upload is successful then I send the image link with the rest of the data to the back-end, but as Im saving firebase credentials (in order to connect) in the app, now Im questioning if it would be better/safer doing it all in the back-end, sending all the information (image included) and the let back-end upload the image to firebase. I don't how how secured are those credentials being of the app
I usually handle things in the front-end if the Firebase SDK has what I need. The only common reasons not to do this, is when there is a requirement to do them in the back-end. This is only common for operations that: require a lot of memory/CPU/bandwidth, require access to secret information (e.g. an API key for a payment gateway), or where the code itself is secret (e.g. detecting cheats in a game, or malicious messages in a chat app).
In your case for example, uploading directly from the front-end to Cloud Storage is a great reason to use the Firebase SDK. Doing so means that Firebase takes care of the encoding, of retrying, of security, and many other things. If you'd want to introduce your own server in the middle, you'll have to write the (client and server) code to handle all of that yourself.
Note that the keys that Firebase tells you to add to your app through the google-services.json are not credentials, but merely configuration data that the app needs to find your Firebase project on the servers. For more on this, see my answer here: Is it safe to expose Firebase apiKey to the public?
But that said, with the configuration data anybody can call Firebase API methods on your project. So you need to secure access in some way, to prevent other users from coming up with their own code that uses your project.
The common way to do this is by using Firebase Authentication on the client to sign the users of your app in. You'd then use the Firebase security rules to limit who can read/write what files in Cloud Storage.
We are using a framework called LibGdx, which allows you to write cross-platform code using only Java. We are developing for Android and iOS.
We have a datastore in Google cloud, as well as an Google app engine api we made to communicate with this datastore.
Now we want to secure this API, but cannot find good guidance on how to approach this for cross-platform. Since we have a mix of fb-login and email-login we need to use client credentials (i.e only our app is allowed to communicate with our API).
Using .NET you would send client credentials (Client ID/Cleint secret), then get an access token, not sure how to approach that in this scenario. We do not have any scopes or anything like that, we just want to secure our API so it can't just be called by anyone. So a simple Bearer-token would solve our issues. Just not sure where to begin.
you should have a look at Firebase Authentication
https://firebase.google.com/docs/auth/
Firebase supports several login providers like Google and Facebook. You will receive a token from Firebase Authentication which you have to forward to your API at Google App Engine.
You can use the Firebase Admin SDK at Google App Engine to validate the Token again
https://firebase.google.com/docs/admin/setup
I have a web application that is written on Python / Google Appengine / WebApp2 framework. The web application has native (custom) authentication. The userid / password is managed by the application (and it does not use Google Accounts).
The web application needs to be extended to Mobile clients as well. So I am developing a native Android Client application and trying to integrate with Google Appengine.
For authentication from the Android Client to the Google app engine, I am trying to keep it very simple by using Google Cloud Endpoints. Can you please suggest if my approach below is correct ?
Generate a white list of client IDs using the Google app engine console (for Android, Web and eventually IOS).
Create a Google Cloud Endpoint backend Api (in Python) with the white list of clients(Web, android and IOS) as suggested here – https://cloud.google.com/appengine/docs/python/endpoints/getstarted/backend/
Create a backend library.
Import the library to the Android Client
My expectation after the above are as follows –
End users using the Google Cloud Endpoints Api (from Android Client) will authenticate the android client with Google App engine.
As part of this secure authentication of the Client-GAE, I can then pass the user login-id as a parameter of the API calls and get data / post data for that particular userid.
I am storing the userid (not the password) for the end-user using local storage in the mobile client.
Can you please suggest if my approach above is correct? I purposefully would like to avoid using Google Accounts based authentication from Android Client to the GAE.
In order to get an App Engine user instance injected into your API method by Google Cloud Endpoints, you do need to be using a Google account in the Android app. The service builder in your Android code takes a GoogleAccountCredential.
You can still support your own userid and password, but you can't leverage the user injection if you do.
[EDIT]
If you're not going to use Google Accounts in the Android app, forget the SHA1 and API key. You're going to have to roll your own auth. It's up to you how you do this, but you might start your session with an API call that takes a username and password and returns a token. All other API calls might take that token and check it for validity before returning a result, for example.
I have an android application and it has a trial version. I want to store users' imei numbers and installation dates on serverside and than check everytime when user uses this app to know if trial version is expired. Since i am not experienced on server side programming i was hoping this kind of cloud service would solve my problem. Before i jump into it i would like to be sure if simpleDB is suitable service for me and if not could you suggest another solution ?
The primary issue is securely storing the access credentials. To access the SimpleDB service without an intermediate server, you'll need to store the access credentials in your Android app. These are accessible with very little skill (text editor?) and could potentially allow unauthorised access to you Amazon Web Services account.
For a while there have been some options for creating extra credentials with varying access levels (eg. read-only) but I've yet to explore this myself.
UPDATE
Amazon have updated their Android libraries with improved credential management. This answer for anonymous, read-only access describes in more detail how to use AWS Identity & Access Management.