I am developing an Android application which requires users to register and log on to a website and then use that registration information in an Android app. Should I be using oauth or openid or is there something better to make it not a requirement that I develop a single-use authentication system?
OpenID
If you're just looking to authenticate a user in your android app without exchanging data between your application and user data stored & managed by a third party service provider (like google,flickr,facebook,....), then OpenID might be the better option for you.
There is a java based library that should work on the Android platform called openid4java.
OAuth
OAuth, although part of the workflow involves authenticating against an OAuth service provider, is more focussed on the authorization part, as it is to a large degree unaware of the underlying authentication mechanism.
If you want your application to act on the users behalf (to fetch user data stored at a third party that supports oauth), then OAuth is an interesting option. OAuth is not capable of acquiring the identity of the user, it merely acts as an authorization mechanism for an already identified user.
Signpost is a java based library that works on Android.
OpenID Connect
For early adopters, another interesting solution on the horizon is Open ID connect, that combines the best of the 2 worlds.
Take a look at the following posts for more background info.
What's the difference between OpenID and OAuth?
http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing
http://thenextweb.com/socialmedia/2010/11/04/facebook-connect-oauth-and-openid-the-differences-and-the-future/
And of course the specs :
http://openid.net/
http://oauth.net/
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'm looking for your input in authentication to a rest api related question.
Now Imagine the following scenario:
I have an android app that wants to use resources provided by an public API called MAIN_API (which i have no control over) that has a universal API key. The API key grants access to risky actions such as deleting records.
Now i want to allow the users of the app to have a very limited access to the API resources, but i want them to be able to use the application anonymously ( no credentials of their own).
I figured that the best way to approach this is to have another server that would contain the API-key and would provide the means for the limited access for the MAIN_API (for example PROXY_API would only call simple query endpoints). The actual mobile app would call this API. Call it PROXY_API for the purpose of explanation
Do you think this approach is enough to stop malicious usage of the MAIN_API? Do you think it would be beneficial to generate some sort of application credentials getting an access token from the PROXY_API?
To provide basic authentication to a web service is quite simple and will depend on the technology stack you are using on the server.
I'd recommend that if you need to both grant users and client applications access to resources to use an authorization mechanism such as OAuth. There are Opensource OAuth server implementations available. Though the OAuth server is a standalone component, securing your resource server to check authorization against the actual OAuth server may depend on your technology stack.
If you are not very knowledgeable about security, and want to control access to your API/Webapp using OAuth, I'd recommend you a service like Stormpath, Auth0 or 3Scale. They first two offer free accounts and can help you kick start your product.
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.
TL;DR: I would like a native (already logged in) Android application provide auth tokens to third party applications installed on same device. I would like to use as much as possible of standard spring-security-oauth2 code as I am no OAuth2 expert.
Long version:
I have a system consisting of:
an Android client application
a central web application exposing some data via REST APIs currently secured by HTTP BASIC. The central app holds a repository of user accounts.
this all works well in an isolated environment.
Turns out third party Android app providers would like to integrate with my system. Actualy no REST API calls will be made - the only purpose of the integration is joined user accounts.
I have created an OAuth2 (spring security based) authentication server that third party apps can use - this way the users can use same credentials both in mine and third party apps.
Thing is: my users still have to enter the credentials at least once for each app. This is cumbersome: my users are kids - they often do not remember or are simply not able to input credentials.
Instead of forcing third party providers embed WebView in their application and handling OAuth2 calls to my server I would like them to call my application which is conveniently already logged in. My app would handle the actual authorization UI (via native activities) and respond back to calling app with proper tokens.
The main problem is: I do not know how to start.
Can I force spring-security-oauth2 to use JSON only? I see that the most important authorization endpoints generate html on the fly.
Do I have to create my own endpoints handling this approach or any standard OAuth2 flow would do?
I am quite new to android and recently started building an application which requires
Registration using a google id.
Continuous interaction with a back-end server.
For the registration , i was wondering if it is possible to have a python webapp on Google App Engine which has the OAUTH2 authentication .
This page if opened in a webview should return the token to GAE (please correct me if i am wrong here , because i am not sure the token won't just go directly to the app).
Then again on the backend i generate a token(newly generated) and update the user tables with this new token and pass this onwards to the application.
Every subsequent request made by the app will be referenced using this token.
Is this feasible or is there a better standard way to do it (i do not want to use the login info already stored in the phone) ?
Also , how can i get information from a google account(name,email) like Facebook has access to the graph is there a google counterpart ?
As far as I understand, you implement your Android app using WebView. This means that the app interacts with the server the same way as the built-in Android web-browser. As a result you don't need to add anything special to your Android app with regards to authentication.
Built-in Users service
In GAE, you get out-of-the-box support for three different types of authentication where all of them are designed in a way that your app doesn't store user credentials but rely on user authentication from identity providers:
Google Accounts (e.g. jonny#gmail.com)
Google Apps Domain (e.g. jonny#mydomain.com hosted in Google Apps)
or Federated Login (a.k.a. OpenID, e.g. Google, Yahoo!), which is going to be replaced by Login with oAuth2 (OpenID Connect)
All three types allow your app only access to very basic information of the user. Enough to match a returning user of your GAE app to their data, and an email address or unique ID, but that's it. For more, see below (oAuth2 consumer).
In appengine console, you can select your preferred authentication type in page Administration > Application Settings.
Whatever of these types you use, in your Python code you can use GAE's Users service which will deal with the authentication of your users. Basically, you just write something like:
from google.appengine.api import users
user = users.get_current_user()
if not user:
# The user is not signed in.
else:
print "Hello, %s!" % user.nickname()
On development server, you will be prompted with a dummy login page for requests where you require login or admin login. In live environment they will be replaced by GAE with real login page flow. There are also articles linked in the docs with HTML/JS examples if you want to show custom login pages to your users, for example User Experience summary for Federated Login
oAuth2 for authentication and authorization with Google
Regarding oAuth2, with the built-in authentication it is rather easy to integrate the builtin oAuth service, so your GAE app becomes a service provider, i.e. a user of your GAE app can share data with any 3rd party app or website through some simple API. You also can have your GAE app consume data that your users have stored somewhere else (e.g. Google) and they want to share with your GAE app (consumer). If you are especially interested into accessing user data in Google services, there is this good overview.
Custom user management
Finally, you could implement your own authentication mechanism, rather than relying (and depending) on GAE features. For example you can implement your custom user management based on webapp2. This means that you have control of the user-accounts and credentials, but aside of eventual security risks the disadvantage is that it can be really hard and tricky to integrate services and APIs like Google Cloud Endpoints.