I don't know whether i am asking a stupid question here.
I am just starting to learn and program android applications.
I wondered :
How is the mechanism of an application and its back-end server works?
How to have a user login and only the contents related to that user is shown?
Which is something like when we login a Facebook account, we will have access to our information only.
Had a looked at SQL server and Data store and it seems like the database is shared for everyone using the application.
Android supports client apps, AppEngine supports server apps, communication between them is HTTP(S).
Endpoints are libraries of client code generated from server projects. Endpoints perform authentication by passing client credentials to the AppEngine server. Client app developers use Endpoint libraries instead of developing networking software themselves.
One of the AppEngine services is the optional Users Service to look up information related to the client credentials. If a server app needs to implement access control, it can be programmed to accept or reject requests per request detail and per user. The application author is responsible for implementing such security.
Related
I want:
central oauth2 server which will hold all user accounts and will provide platform for user account management
multiple services which will connect to central oauth2 server to verify user. Each service will have Web and mobile applications (iOS, Android)
I followed spring-boot-oauth tutorial and have client that connects to server for credentials using redirect. This works fine for browsers, but I wish to be able to login directly in native apps. I think using grant_type=password should solve the problem, but I can not find good description how to approach this.
Should I send token request directly to central server for refresh token, or should I proxy it through each application service?
Is there any way to check on native app if user is already logged in central server from device, or do I always need to send login/password? I'm aware that I could develop separate application to which I will redirect user for verification, but for user-experience and time-efficient reasons I would like to avoid it.
If you are thinking of native mobile apps on Android and iOS, then I would recommend looking at these libraries...
https://openid.github.io/AppAuth-iOS/
https://openid.github.io/AppAuth-Android/
These libraries allow you to use implicit or code authorization flows, avoiding the grant_type=password flow which makes it more difficult to get single sign on.
I am creating an Android app that will be using a Django backend, along with the Django Rest Framework. I have been reading the OAuth2 documentation, but am still struggling to understand a few key points about its authentication.
These are my main questions/things I'm struggling with:
In OAuth2, I am given the oppurtunity to create 'apps'. Would the 'app' in this case be specific to my Android app (and presumably in the future I would create a different one for a potential iOS app?).
Will all users of the (Android) app be using the same token, or is each user granted an individualized token?
I am using the Volley library for Android to deal with networking. How do I go about getting the Android app to 'store' the needed credentials? Would I be storing the token, id, and secret, or just the token?
If it is worth noting, I do not plan on adding social media logins (Facebook, Google, etc) I will just have login be with a username and password.
I'm sorry if these questions seem a bit elementary, this is my first experience will authentication of any sort.
Thank you
I'll be using the word "app" to mean two different things:
app, to indicate Oauth2 app, which you'll create to register your mobile app(s)
app, to indicate mobile app.
Answer 1:
An app is basically a way of registering a client (in this case, your mobile app) with the resource server (in this case, you Django backend). You can go either ways, creating two separate apps or a single app for your Android and iOS apps. Unless you are not planning to give users of one app some more privileges or features, I don't see benefit in creating two separate apps.
Answer 2:
Each user is granted a different access token.
Answer 3:
You'll have to store client_id and client_secret in some secure way on your mobile app(s). Because that's what will help you gain an access token for a user, in first place. You'll also store access token after obtaining it, because it will be needed in making authenticated HTTP requests.
For more information on Oauth2 Protocol in general, you can read this answer, and Oauth2 Protocol RFC.
I'm working with mobile apps and RESTful APIs and I have some doubts about security when registering a new user. I'm developing an android client that will communicate with a backend through REST requests.
It is very clear to me about the usage and implementation of the OAuth Authorization Server and how the communication is made between the android client (frontend) and the resource server or the authorization server (backend).
Most of the documentations mention that the client_id and client_secret must be stored in the server instead of the mobile app to avoid that such data to be figured out in an eventual decompilation proccess.
If I wish to perform an activity to create a new user, directly in the app (as it is the case in apps like snapchat, pinterest and so on), how could I perform the communication of the client with the REST API without the client_id and client_secret (or any kind of credentials) in the app?
The first and easiest solution would be to redirect the user to a signup webpage, but how could it be made in the APP?
https://stackoverflow.com/a/14572051/5055317
Simple answer: no data on the .apk is safe.
There are many ways to hide your API keys inside the apk. For example, using obfuscators like ProGuard/DexGuard, using Base64 encoding or hiding these Strings with JNI. But at the end they just create some delay to obtain the keys.
The only way to keep this information safe is if it is stored in a server, and your app gets it when needed.
Here is an article by Michael Ramirez review about hide techniques: https://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/
And here a discussion about this topic with some google employees: https://groups.google.com/forum/#!topic/google-places-api/SmujrL-pDpU
I'm building a Android/iOS/Web app which authenticates with a provider to receive an access token and then uses the token in the API calls to the node.js backend. I've already got it working for facebook using Passport and the Facebook-Token strategy (https://github.com/drudge/passport-facebook-token)
Now I'd like to repeat the process with this library https://www.npmjs.org/package/passport-google-token
Should be easy, right? But google's developer console for android doesn't provide a client secret. Infact there is very little documentation on what to do if you would like to authenticate on the device and use a token to communicate with the server. It was so simple with facebook, is there something I am missing?
FB's (or Google's) access_token is for their API, not yours. Also, most flows with 3rd party providers like FB and Google are intended for web sites (this is the auth code grant). Devices (and SPA) typically use the implicit flow that doesn't require secrets on the client.
You might want to consider authenticating users with Google or FB (or whatever) in your website (using either strategies which are optimized for web flows), and then issue an API specific token derived from that. I would recommend issuing JWT, which are lightweight and simple to use.
On the API side you could use express-jwt. See here for additional details.
I have a simple Google App Engine backend (written in Python) for an Android client. All the backend is responsible for is accepting a key and returning a value; it is a classifier in general, implemented simply by looking up the key in a Cloud SQL table, though this specific behavior will change in the future.
The backend and client communicate via Google Cloud Endpoints. I want to restrict access to my backend's API to only accept requests incoming from my client, and am wondering if OAuth 2.0 is really the way to do this.
I don't need any contextual or extra information from the user, and as such, don't want to have user action to grant any type of authorization. All I need to do is be certain the request came from my app. I was considering simply generating a static key and hardcoding it in my client and backend, but I thought there must be a more elegant way to do this.
TL;DR: How can I restrict access to my backend only to my client/app without needing user context/input, by OAuth 2.0 or otherwise?
I don't know if the OP solved their problem but I am posting this here for others. I have wasted quite a few hours on this particular issue.
Steps :
1.Create an oAuth 2.0 client ID for your Android client.
2.Specify the Client IDs in the allowed_client_ids argument of the endpoints.api. In this case (Android), supply both its Android client ID and a web client ID in allowed_client_ids.
3.Supply the audiences argument as well in endpoints.api which is set to the web client ID.
4.Add a user check to the protected methods.
5.Redeploy the API backend.
6.Regenerate the client libraries.