tags:

views:

45

answers:

1

Is there any free single-signon mechanism for Android that gracefully works with non-webapps? Say, something along the lines of...

  1. You launch my app and use it until it makes a request from the app server that requires authentication. It responds to that request with a random token that the server will associate with you for a short time.

  2. The app presents you with a username field, a password field, and a submit button.

  3. You enter your username and password. The app then forwards your username and hashed password, along with the token generated by the app server, to the login service.

  4. The login service determines whether or not your username and password are valid. If they are, it digitally timestamps and signs the token, and returns the signed token to the app.

  5. The app relays the signed token to the server.

  6. The server checks the signature, satisfies itself that it's valid and signed by an authority it trusts, and proceeds as though the user had presented IT with a valid local username and password instead.

I suspect I'm just getting lost in nomenclature, but the impression I've gotten so far is that all the usual SSO providers -- Twitter, Facebook, etc -- only allow users to log in using a normal browser, and that you're either not allowed to do what I described, or they do something to make it effectively impossible with anything besides a normal browser (like dynamically creating the login form via Javascript in an effort to prevent developers from trying to use their own apps as a login facade).

Alternatively, does there exist any workflow like THIS...

  1. You launch my app and use it until the web service requires you to log in. The app server generates a token and returns it to the app.

  2. The app spawns a new browser via intent that sends you to the login provider's web site, passing the token via intent to the browser (and ultimately the provider) as a POSTed formvar.

  3. You log in using the browser window, and the browser window closes -- returning you to my app.

  4. The login provider signs the token, then sends it directly to my app server via HTTP POST so I can note its submission, verify the cert, and treat it as though it were instead a valid username and password submitted directly by the user to the app server himself.

A: 

Could you use openids?

ekawas
Er, maybe. In the case of OpenID, I guess a better question might be, "does there exist somewhere a coherent explanation of how to actually use OpenID in a real-world Android app with non-theoretical users?" So far, everything I've tripped over has been kind of like "This is how xxx is theoretically supposed to work, but to date nobody has actually pulled it off yet... or they did, but something that happened a few months later broke it."
Bitbang3r
ekawas