How to authenticate a mobile application without a username and password?

Question

I am creating a Webapp that uses OpenId to authenticate users, for example, Stackoverlfow. There will also be a mobile application, for example. Android or iPhone. These applications must be authenticated or logged in to access data and update user-owned material. Since there is no username and password that could be provided for authentication of a mobile device, I wonder how to achieve this.

It occurred to me two ways:

• Create several keys on the server that must be entered on the device. This key will be sent as an authorization key when the mobile device sends or requests data, and the user can be connected in this way. When using this parameter, the key must somehow be transferred to the user, so he does not need to enter it. Perhaps by email, SMS or barcode scan.

• The mobile application uses a browser or displays an integrated web panel that opens a special Webapp page. On this page, the user must log in and then allow the mobile application to read and write data.

My question is: are both ways possible and persist? Which one would you prefer? What are the details you need to pay attention to? Are there any other ways to do this? If I succeed, it would be impossible to use OpenId on the device and connect mobile and webapp in this way, right?

Answer 1

To do this, I did the following:

• When the application starts, I test if there is an authentication token and if it is still valid
• If not, I use [startActivityForResult] [1] to open my login activity.
• LoginActivity uses a WebView and opens the "authenticate application" page (for example, https://www.yourdomain.com/authapp ) from a web application.
• If the user has not logged into webapp, he should do it now. After a successful login, it is redirected to the "authenticate application" page.
• The "authenticate app" page contains the text "Do you want the mobile application to access your data" and the "grant" and "cancel" buttons.
• If the user clicks “grant”, the web application generates an authentication token, writes it to the database and redirects to the response page, attaching the generated authentication token to the URL (for example, https://www.yourdomain.com/authresponse?auth_token= dshf84z4388f4h )

• The mobile application extracts the token from the URL and uses it for authentication when talking to the server.

  The activity of WebLogin is as follows: (note: you need to override "shouldOverrideUrlLoading" to stay in the same WebView. Otherwise, the new browser will open when you get some redirects)

  the public WebLogin class extends the {

  @Override protected void onCreate (Bundle savedInstanceState) {super.onCreate (savedInstanceState);

  WebView webview = new WebView(this); webview.setWebViewClient(new WebViewClient() { @Override public boolean shouldOverrideUrlLoading(WebView view, String url){ view.loadUrl(url); return true; } @Override public void onPageFinished(WebView view, String url) { if(StringUtils.contains(url, "?auth_token=")){ // extract and save token here setResult(RESULT_OK); finish(); } } }); webview.loadUrl("https://www.yourdomain.com/authapp"); webview.getSettings().setJavaScriptEnabled(true); setContentView(webview); 

  }}

Note. I use https to create this save. If you use simple http, you can read and steal the user's token.

[1]: http://developer.android.com/reference/android/app/Activity.html#startActivityForResult(android.content.Intent , int)

Answer 2

The current OAuth specification (RFC5849) still requires the user to enter their credentials on the website where the secure resource is stored. In a mobile application, this user interface is not the best (as you indicated, it is required that the mobile application displays an auth page with a built-in web view). OAuth 2.0 solves this problem by specifying different types of access. This standard is still in draft. Until then, your best bet is probably to change the OAuth 1.0 streams to fit your mobile device, as there are already a large number of large sites (e.g. Twitter with xAuth and Dropbox with their developer APIs ).

Answer 3

I am doing something similar to option (1). Create a unique link (even just provide a session identifier), and then send it via SMS. To do this, there are many cheap sms package providers with simple APIs. When a user clicks on a URL in an SMS message, he will open a mobile web browser and register it.

After that, if the phone accepts cookies, you can set it. Otherwise, the user must always log in through this unique link.