OAuth 2 meets user friendly

21 Jul
2010

OAuth is a perfect solution for authentication with other web apps. The problem is, it just sucks for native apps.

You know the typical workflow for apps. Open, enter credentials, it works. Now here’s what OAuth looks:

Yes, it quit’s the app, opens Safari, and then restarts the App. Yes, this sucks. But see for yourself

Even worse, some other apps like Echofon like to play the travesty role and ask your two times.

OAuth may provide an improvement in security, but most end users don’t care or just don’t understand. Our job is to provide reasonably good security AND maximizing the user experience. Closing an app, opening a browser and forcing a user to copy a token IS NOT user friendly.

There was a big outcry by some people, especially UX affine ones, when Twitter announced shutting down their http auth, leaving only OAuth. Twitter listened and presented xAuth. It basically hides everything from OAuth, let the user enter his credentials the old way while transparently fetching the token. hen some other people say this is a terrible, horrible, not good, very bad idea…

So what else is there?

Facebook’s new Graph API is probably the most known OAuth 2 API. They provide a full package for the iPhone that manages all authorization  in the browser, yet in a very user transparent way. Sure, this is a security risk. With some easy hacking and/or javascript injection you can steal the login data. But it’s certainly saver than letting the application store the credentials.

Problems

  • Creating multiple accounts is a PITA, requiring multiple roundtrips and logging in/logging out of the service. (This is less of a problem if you make the login convenient via a optimized landing page; and you don’t have an automatic login)
  • The Consumer Secret is reverse engineer-able. This nullifies the argument that oAuth is better for identifying clients when it comes to desktop/mobile apps.
  • If a native app wants to get a copy of your password, it will get a copy of your password. It can create embedded browsers, hijack the authentication, add a proxy or else.

Loren Brichter proposes a solution that integrates deeply with the OS, therefore maximizing security while keeping the “native” experience.

Advantages

  • From a service provider’s point of view, it’s absolutely reasonable why the want OAuth. Control. Which is a good thing.

OAuth doesn’t prevent evil folks from shipping Twitter apps that might be trojans, but it does allow us here at the Mother Ship to revoke their ability to talk to the Twitter API. That means less spam/”SEO” tools, and a short time-to-live for applications that are discovered to be malicious. [Alex Payne - API Lead, Twitter, Inc.]

  • For the user this is also a good thing. You can loose your iPhone and just disable the specific token. Your password is not leaked. The App furthermore could be configured to clear all caches when it detects that the API Key has been revoked.
  • It’s better than Basic access authentication, where your username and password is sent in every single request. But you have to go over SSL anyway. If your token leaks, other’s have access to your account.

My proposal

I’ll propose something similar. A optimized, secured landing page that is styled native-ish per device and runs within the native browser, but without showing the user so. So we can provide a good-known-flow

  1. Open App
  2. Press Login / Register
  3. Wait for login page to load (this is where users may experience a little difference…)
  4. enter credentials
  5. wait for authorization
  6. it just works!

Of course, the web service has to provide some sort of management page where current applications are listed and rights can be revoked. If a application goes wild and messes around with usernames, their token can be blocked. (which only makes sense if there’s a reasonable review in application registering)

There’s some comparison of the different techniques on the oauth wiki native apps page; but no clear winner.

Raus aus dem T-Mobile/tele.ring Vertrag? Jetzt ist eure Chance!

25 Jun
2010

Wer Zweifel hat, dass das nicht funktioniert, möge hier und hier nachlesen. Geht aber logischerweise nur bis zum Inkraft-treten der neuen AGB am 24.7.2010.

Die neuen AGBs bieten eigentlich NUR Nachteile – ich sehe keinen einzigen Punkt der eine Verbesserung für die Kundenseite bringt.

Hier gibt’s TKG 2003 §25 zum Nachlesen.

Und besser schnell sein… Big Bob gibt’s nur noch bis zum 30. Juni 2010!

Leider lässt sich ein iPhone 3GS mit neuen Boot Rom (iBoot-359.3.2) noch nicht entsperren. Obwohl @geohot noch ein Ass im Ärmel hat, ich stecks einfach in mein neues simlockfreies iPhone 4 aus England ;)

Read the rest of this entry »

Add Facebook Like Button with Facebook Connect iPhone SDK

25 Jun
2010

Like buttons are everywhere, so this is supposed to be easy with the facebook-iphone-sdk. It is not. Liking is not a supported action from the SDK. Only via facebooks iframe.

I present you a clever workaround, that even uses the sdk to display a *conventional* facebook login in a way the user knows.


Read the rest of this entry »

Use TTURLXMLResponse with server that send you the wrong encoding

24 Jun
2010

That took long. I am parsing RSS, but _one_ particular feed would not parse, the console screamed “NSXMLParserErrorDomain error 9″.

So some stuff in encoding was weird. I replicated the feed on my server, voila, worked like a charm. http://beta.feedvalidator.org finally brought some light into the issue: “Your feed appears to be encoded as “UTF-8″, but your server is reporting “iso-8859-1″”

Okay. So the server fucked up. But we can’t change that, so let’s make our parser more robust. I am using TTURLXMLResponse (see their TTTwitter example on github)

So let’s override that! See the middle part for my change/hack/improvement. (Call it whatever you want)

@implementation VIURLXMLResponse

///////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark TTURLResponse

// overridden from TTURLResponse to hack around voest rss feed!
- (NSError*)request:(TTURLRequest*)request processResponse:(NSHTTPURLResponse*)response
data:(id)data {
// This response is designed for NSData objects, so if we get anything else it's probably a
// mistake.
TTDASSERT([data isKindOfClass:[NSData class]]);
TTDASSERT(nil == _rootObject);

if ([data isKindOfClass:[NSData class]]) {
NSString *utf8Response = [[[NSString alloc] initWithData:data encoding: NSUTF8StringEncoding] autorelease];

// oh ooh. server sent us data in ISO-8859-1? [hack around standards]
// http://stackoverflow.com/questions/1207867/nsxmlparser-rss-issue-nsxmlparserinvalidcharactererror
if (!utf8Response) {
NSString *dataString = [[[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding] autorelease];
data = [dataString dataUsingEncoding:NSUTF8StringEncoding allowLossyConversion:YES];
}

TTDCONDITIONLOG(TTDFLAG_XMLPARSER, @"Data: %@", [[[NSString alloc] initWithData:data encoding: NSUTF8StringEncoding] autorelease]);

TTXMLParser* parser = [[TTXMLParser alloc] initWithData:data];
parser.delegate = self;
parser.treatDuplicateKeysAsArrayItems = self.isRssFeed;
[parser parse];
_rootObject = [parser.rootObject retain];
TT_RELEASE_SAFELY(parser);
}

return nil;
}

@end

TTStyledText and ampersand (’&’)

24 Jun
2010

My styled text disappeared sometimes. I tracked down the problem. You’re not allowed to have bare ampersands in the styled text. Replace them with the html-encoded variant and everything works fine.

  // fix styled text for apersand problems
  styledText = [styledText stringByReplacingOccurrencesOfString:@"&" withString:@"&"];

Other than that, TTStyledText is plain awesome, so is the whole three2 framework (extracted from the facebook iPhone App)

Older Entries
Newer Entries
top

Switch to our mobile site