Simon Willison's Weblog: idproxy

OpenID phishing demo

2008-05-28T08:09:23+00:00

A demonstration of the OpenID man-in-the-middle phishing attack. idproxy.net OpenIDs are immune to this particular variant due to the landing page not asking for your password (the phishing site could still provide their own redesigned landing page and hope users don’t notice though).

Via Mike Jones

Tags: idproxy, openid, phishing, security

OpenID for Google Accounts

2008-04-09T01:09:40+00:00

OpenID for Google Accounts

Google App Engine integrates with Google’s user accounts, so Ryan Barrett (of Google) used it to build an idproxy.net style OpenID provider.

Tags: google, google-app-engine, idproxy, openid, ryan-barrett

Windows Live ID Web Authentication Released!

2007-08-17T10:20:59+00:00

Windows Live ID Web Authentication Released!

Passport lives again! Who’s going to be first to build an idproxy.net for it?

Tags: idproxy, microsoft, openid, passport, windows, windowsliveid

Partial OpenID provider implementation from idproxy.net

2007-07-12T18:48:55+00:00

Partial OpenID provider implementation from idproxy.net

It’ll take a while to package up provider support for django-openid, but in the meantime here’s some partial, incomplete, poorly documented example code ripped from idproxy.net. Hopefully this will give people trying to figure out the JanRain Python library a bit of a leg up.

Tags: django, europython, europython07, idproxy, openid, partial, python

A note about simple registration

2007-06-30T21:28:30+00:00

Simple registration is an extension that allows OpenID consumers to ask your provider for extra information - your name, e-mail address, date of birth and so on.

Unfortunately, the spec often causes confusion for implementers. Here's the tricky part:

openid.sreg.required:

Comma-separated list of field names which, if absent from the response, will prevent the Consumer from completing the registration without End User interaction.

openid.sreg.optional:

Comma-separated list of field names Fields that will be used by the Consumer, but whose absence will not prevent the registration from completing.

This is often interpreted as meaning that you can pass along a list of required fields and be guaranteed that they will be handed back to you. This is not the case: some providers (idproxy.net for example) don't support simple registration at all; others (like WordPress.com) only support a subset of the fields, since they don't store details such as the user's postcode. If your provider insists on certain values being returned by simple registration, some of your potential users will be unable to sign in.

The misunderstanding stems from the definition attached to the required field. When you make a simple registration request, you're providing advice to the provider. You're essentially saying that the user is going to have to provide this data eventually in order to register with your service, so it would be really handy if the provider could send it over to you. If they don't, your application will have no choice but to ask the user for it directly.

In other words, even if you specify required values you shouldn't expect them to come back every time.

By far the best way to use simple registration is as a way of pre-filling a signup form for your user. Many applications ask the user to complete a short registration form the first time they sign in with their OpenID. Use simple registration to pre-fill some of those form values - that way, if it's not available (or some of the values are missing) your application logic doesn't really care, it's just one more form field that the user will have to complete themselves. Ma.gnolia.com is a great example of a site that does the right thing.

See also this thread on the mailing list from back in March.

Tags: idproxy, magnolia, openid, sreg, wordpress

OpenID as easy as 1,2,3

2007-01-30T00:27:03+00:00

OpenID as easy as 1,2,3

An idproxy.net walkthrough, with screenshots.

Tags: howto, idproxy

idproxy.net: Use your Yahoo! account as an OpenID

2007-01-27T20:17:54+00:00

In an ideal world, some or all of the sites with large user databases (Yahoo!, AOL, Google, Amazon and so on) would act as OpenID providers, allowing their users to sign in to OpenID supporting sites around the Web. Until that happens, people who want to use OpenID need to sign up for Yet Another Account to do so.

idproxy.net, launched today, is my attempt at speeding up the process. It uses Yahoo!'s Browser-Based Authentication API to allow you to sign in with a Yahoo! account, then lets you create one or more OpenIDs (of the form something.idproxy.net) to use with sites that support the OpenID standard.

In effect, it lets you use your Yahoo! account as an OpenID.

Phishing protection

I've built in a couple of features to help protect users against phishing attempts.

The first is based on Andreas Gohr's MonsterID. When you log in for the first time, you are asked to pick one from a selection of four random monsters. Your monster will greet you when you log in to the site, helping defend against malicious sites that try to copy the "logged in" view.

The second is a landing page based on my suggestion from last week, which requires you to log in manually or with a bookmark rather than presenting you with a login link directly. This is similar to MyOpenID's SafeSignIn feature, but it's on by default and you can't turn it off.

The nature of the site means that a successful phishing attack would have to compromise your Yahoo! account as well. Yahoo! have their own phishing prevention in the form of the Yahoo! personalized sign-in seal (similar to the idproxy.net monster, but visible before you log in).

Other providers

An older (unreleased) version of the site included support for Flickr, Upcoming and Google authentication. I've dropped those in favour of Yahoo! for a couple of reasons. Firstly, supporting just one form of authentication makes the site easier to explain. Secondly, none of those APIs were designed with single-sign-on in mind. All three exist primarily to give a third party service access to your data; as such, their authentication flows include permission pages which warn that idproxy.net will have access to your private photos, events or calendar.

I'm very open to suggestions and feature requests. The top of my list at the moment is an interface for viewing and changing the list of sites which always have access to your identity.

Tags: idproxy, monsterid, openid, phishing, projects, yahoo