So I learned the basics of android but I never understood this part.
I know when using websites, authentications are made along side sessions and cookies. But what about android?
When an authentication is made, a token is generated, right? where does this token belongs in android application world? is it stored in AccountManager ? should it be stored on SharedPreferences ? I also saw something called OAuth2 but didn't get what that is.
I'm sorry if my question is stupid but it is driving me nuts in a long time.
if you have a good tutorial for these kinds of web services, where they teach real world coding examples, please let me know.
Most modern Android apps use HTTP client to do backend calls, for instance Retrofit. I would suggest reading a bit about Retrofit and about how you can use this token
More about authentication token and Retrofit, here
As to where to save the token, in my current project I save the token in something similar to a static field. more info here
Related
I want to develop the Android client for my RESTFull Web service. But, I'm nearly newbie in Android and I don't know how to make correct authentication with REST service. How to save user details in android ?
This is a fairly complicated topic that is too broad to explain fully here. I highly recommend Retrofit for this. Here's a link to their site, http://square.github.io/retrofit/
I've also put together a sample project that gets images from imgur api using retrofit if you'd like to learn more about the implementation.
https://github.com/mmeister1203/SampleRetrofitApp
For authentication, I suggest you use Authentication token. It basically works this way:
You send user details to server(through https, of course).
You receive authentication token, which you save in, lets say, SharedPreferences.
Every time you make a web request, you include your token the request.
This is most common approach when you don't need extremely high security.
I am working in a app that register a user in a specific place.
I got the client_id and the client_secret and the url, also the token url.
i have seen how simple was to use the AFOAuth2Client in Iphone and i would like to know if there is an equivalent for Android.
Thanks in advance.
It's generally not a very good idea to store secrets on a device. If you control the entire stack: client, API and AuthZ server, then make sure you use a Oauth2 flow that doesn't require that. (Or reconsider using Oauth2 altogther perhaps).
The simplest Oauth2 flows are quite simple to implement as they are straight forward HTTP requests.
I'm trying to setup a private oauth2-server for usage with Android. I don't want any 3rd party-server to authorize, so my question is how to do this?
I had a look at Apache Oltu, but I haven't been able to find any HowTo to setup the server. Are there any instructions available or could someone who already did this help me?
Furthermore, is there a better solution? I don't want to just provide user/pwd-authorization (or even digest), because it's about getting an user-specific file, which should be automatically synced once in a while without asking for a password again.
The Apache Oltu documentation contains some example code, which should help you understanding the basics. Then you should have a look at the integration tests, which contain code for nearly all use cases.
But you have to understand that Apache Oltu isn't a standalone solution. It's only a framework, which handles the network communication for OAuth authorization and resource requests. That means, you have to implement
your own persistence layer for storing tokens.
your own security interceptor which actually checks if the received token is valid. Oltu isn't integrated into the webserver, so you have to take care that requests don't bypass OAuth authorization.
your own user registration process.
This is an "Is this possible?" question. I have an app for the android phone and another application for the appengine platform. The appengine thing is really just a db of high scores, and the phone app is really just a game. I can, using some json/gson/httppost stuff, send the scores from the game to the db. Now I want to make sure that the scores I have collected come from the game, not some guy, maybe talented at programming but with too much time on his hands.
Here's the question. Can I use google OAuth 2.0 to somehow authenticate that the scores I'm getting come from phones running my game?
I thought I'd do this: I'd use OAuth to get some kind of token from google (from the phone), then pass that token to the appengine database (using a json record), then use the token to get info from google on the user. This could be as simple as an email address. Then I'd say to myself "Well, as long as I get an email address for the user, then I know that the user is using the game, and I can store their score." Does this sound possible? I get the feeling that once I use the phone to get the token from google, it's unusable by the appengine program.
I was thinking I'd use the client_id and client_secret, (and whatever else I needed) that were associated with the appengine db to get a token from the phone, then when I sent the token via json to the appenging program to get the email address, they'd work from appengine. This seems like somehow the google OAuth would know that I was trying to get a token from a phone, and then would reject the whole thing. Then again maybe it would work. They say though that android phones cannot keep secrets (referring to the client_secret).
Finally I was wondering if there was any other easier way of making sure that the score I was recording at the appengine side was truly coming from an android phone running my game? Can I set up my own authentication scheme? How hard is this to do?
Good timing; Google just released a feature will address your question:
http://android-developers.blogspot.ca/2013/01/verifying-back-end-calls-from-android.html
Doing this is a multi-step process, which I’ll outline in full, but
here’s the short version: You use the GoogleAuthUtil class, available
through Google Play services, to retrieve a string called an “ID
Token”. You send the token to your back end and your back end can use
it to quickly and cheaply verify which app sent it and who was using
the app.
With OAuth 2.0 (Open ID connect) you can identify the user that is using your game. It seems that you want to authenticate the app though. There are multiple ways to do this, but you still have to embed the credentials in the app or create some sort of registration mechanism. Generally, as long as your attacker (skillful user) has full access to app code and the device (rooted, etc.), there is not much you can do. The only question is who hard do you want to make it.
Or you can use a third party service such as Parse, and trust that they spend some time perfecting their app authentication mechanism.
I'm currently designing a service that will be half web app, half android app. Each user will need to be able to log in from either the android app or the web app, using an openID account. I'm hoping to target Google first for easiest integration with Android, but I'll also need some OAuth stuff later so that I can integrate with Google contacts.
The bit I'm having trouble with is how to authenticate users. The structure I've planned is that the server (probably using web.py, although that's flexible right now) serves data for the client in JSON, whether the client is the javascript browser client or the android client. However, each call needs to make sure the client is allowed access to that data.
What would be the easiest way to standardise this across the platforms?
Should I be using a session system to authenticate after logging in? Can that be made to work from an Android app? Otherwise, should I simply authenticate with google for every request?
When authenticating from the app, where should the authentication happen, through the server or straight from the app? Where should the auth token be stored in this case? (I'm assuming for a straight webapp the token should just be stored in a table in the user database?)
Sorry for the barrage of questions, but I haven't really found any resources online that clarify these issues very well.
As long as you are using HTTP, the platform doesn't matter. You can use the same form of authentication and/or sessions. The only difference would be that on Andorid you might be able to get an authentication token using the platform's AccountManager, without having to type the username and password in Google's login page.
There's a subtle difference between Authorization (OAuth) and Authentication (OpenId). Make sure you know what you are doing.