I want OpenID on GAE / J. I do not want another + 100KB JAR. Did i lose?

Question

Usually people request a "better library", but I assume that OpenID authentication is just a few requests to / from ...? And I'm on GAE, where more JARs mean slower cold start. For example, openid4java-0.9.5.jar has 190 KB. This is like the insanely high cost of some URL requests and text parsing.

Am I missing something? What is more complicated that is necessary when requesting access_token and user information from Facebook?

Are there any well-explained ways? ( This looks good , but seems to be useful only for Google accounts.)
Or authentication, which complicates (or identity providers that are incompatible) that I should just accept + 190KB and add them to my JARs? (Or maybe wait with OpenID for now.)

Answer 1

Use federated login features provided by the Google App Engine. Federated Login refers to any service that allows users to create a single ID or account and use it to authenticate with different services. OpenID is the only federated login supported by the Google App Engine user service .

More information about authentication options can be found here: http://code.google.com/appengine/docs/java/users/overview.html#Authentication_Options

And I would recommend reading the “User Summary for Federated Login” also: http://sites.google.com/site/oauthgoog/UXFedLogin/summary

Answer 2

I think it's always better to use a good library than to write a thing yourself. Is 100 kB a big sum for server code? If you really want to reduce the size of your final code, it is better to use a good obfuscator, for example ProGuard can shorten method names and remove unnecessary code.

But remember that premature optimization is the root of all evil - such landing JARs can make a big difference for applets or other code that users need to download, but IMO has little sense for server applications.

Answer 3

+1 for standard Open Id (albeit experimental) support in GAE

However, I used RPX (now janrain): http://www.janrain.com/products/engage eariler. It fits nicely into your requirement - there are no cans, the least amount of code and support for all connections to the open / social interface. All you need for a public callback url.

Check this!