I have a Java based web application which is developed using JSP/Servlets running on Tomcat server. This application is developed for customer support. A customer can directly login to the application with his credentials and raise any complaints reg. a specific product. He can also view all the complaints he has raised and their status. Also he can add comments to the complaints and also close them when he desires to.
Now I would like to develop an Android app where a customer can login with his credentials and do same operations as he used to do in the above said web application.
I have basic knowledge on Android and good amount of knowledge in Java. Can someone help me with some guidelines or sample source code to develop such kind of application. In particular after authenticating a customer with his credentials from an Android activity by sending HTTP request to the web application, how do we keep track of the session for that customer in order to display him the complaints raised by him or allowing him to add comments to his complaints in next activities (screens). To put it simple how to maintain sessions?
Thanks,
You question is pretty specific to your application. How you maintain a session with the server is pretty much up to you, but you can think of it as implementing the relationship between a web browser and a web server.
After your user logs in, the client should receive some kind of token from the server (similar to a cookie). All subsequent requests will pass along that token to authorize the user, so you'll have to persist it on the device. Your server will have a mapping of tokens to users.
I would recommend looking into OAUTH2 and maybe taking a look at some well used APIs like Twitter and Foursquare for some ideas about best practices.
Related
We have implemented a Backend Server and a DataBase, with RESTFUL API. We have an Android App that can ask the server to send certain data back.
We want to implement an authentication system on the Android App.
The team suggests that I use Spring and OAuth, but I personally have no experience with those, and am not exactly convinced about the necessity of this approach.
Other friends suggest using FireBase to authenticate the users.
Could I avoid using OAuth/FireBase and simply store in the Server's Database the user's account name and its corresponding hash-salted password, along with the salt? Every request sent from the client would contain the account's name (which could probably be a unique ID generated by the server on the very first request, and saved as a SharedPreference in the phone) and the password in clear. The transmission of the request being done via HTTPS protocol (thus using TLS/SSL), the password in clear would not be revealed.
What are the possible flaws to the suggested approach in the last paragraph? And if it is a flawed approach, considering we already are using Spring for the Server (Backend), should I go for FireBase or OAuth ?
Additional context:
Bare in mind that this is the very first largish-scale project that I have been working on (it counts as a 3-credits University course). We are 3 on the project. I'm studying Computer Science but I do not necessarily have a great grasp on all the systems we are using or plan on using.
We are creating an app which allows users to view on a map alerts published by certain databases (we are currently focusing on meteorological alerts) in real-time. We want to be able to implement a login system so that people can receive notifications despite the application being closed (we are allowing users to "subscribe" to areas on the map, to specify the regions they want to receive notifications for).
OAuth, or better OpenId Connect, is a protocol, while FireBase is just one of its' commerce implementations. It's always better to follow a standard where possible than to implement your own. To see the full list of the certified OIdcC implementations look at the OIdC site, and I see at least MITREid Connect project related to Spring. I think your custom solution will work for your custom case, but only until you think about any extensibility such as Google auth or accessing some 3-rd party API.
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.
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.