Instead, you need to create an "OpenID Connect" provider. Here's how.

OpenSteetMap

As per the OAuth documentation you will need to:

• Register a new app at https://www.openstreetmap.org/oauth2/applications/
• Give it a name that users will recognise
• Give it a redirect of https://Your Auth0 Tenant.eu.auth0.com/login/callback
• Tick the box for "Sign in using OpenStreetMap"

Once created, you will need to securely save your Client ID and Client Secret.

Auth0

These options change frequently, so use this guide with care.

• Once you have logged in to your Auth0 Tennant, go to Authentication → Enterprise → OpenID Connect → Create Connection
• Provide the new connection with the Client ID and Client Secret
• Set the "scope" to be openid
• Set the OpenID Connect Discovery URL to be https://www.openstreetmap.org/.well-known/openid-configuration
• In the "Login Experience" tick the box for "Display connection as a button"
• Set the favicon to be https://blog.openstreetmap.org/wp-content/uploads/2022/07/osm-favicon.png or other suitable graphic

Next Steps

We're not quite done, sadly.

The details which OSM sends back to Auth0 are limited, so Auth0 is missing a few bits:

{
    "created_at": "2026-02-29T12:34:56.772Z",
    "identities": [
        {
            "user_id": "openstreetmap-openid|123456",
            "provider": "oidc",
            "connection": "openstreetmap-openid",
            "isSocial": false
        }
    ],
    "name": "",
    "nickname": "",
    "picture": "https://cdn.auth0.com/avatars/default.png",
    "preferred_username": "Terence Eden",
    "updated_at": "2026-02-04T12:01:33.772Z",
    "user_id": "oidc|openstreetmap-openid|123456",
    "last_ip": "12.34.56.78",
    "last_login": "2026-02-29T12:34:56.772Z",
    "logins_count": 1,
    "blocked_for": [],
    "guardian_authenticators": [],
    "passkeys": []
}

Annoyingly, Auth0 doesn't set a name or nickname - so you'll need to manually get the preferred_username, or create a "User Map":

{
  "mapping_mode": "use_map",
  "attributes": {
    "nickname": "${context.tokenset.preferred_username}",
    "name":     "${context.tokenset.preferred_username}"
  }
}

There's also no avatar image - only the default one.

Getting the Avatar Image

The OSM API has a method for getting user data.

For example, here's all my public data: https://api.openstreetmap.org/api/0.6/user/98672.json - thankfully no authorisation required!

{
  "user": {
    "id": 98672,
    "display_name": "Terence Eden",
    "img": {
      "href": "https://www.gravatar.com/avatar/52cb49a66755f31abf4df9a6549f0f9c.jpg?s=100&d=https%3A%2F%2Fapi.openstreetmap.org%2Fassets%2Favatar_large-54d681ddaf47c4181b05dbfae378dc0201b393bbad3ff0e68143c3d5f3880ace.png"
    }
  }
}

Alternatively, you can use the Unavatar service to get the image indirectly.

I hope that's helpful to someone!

There is no way to update the logo of a custom social connection on Auth0 without using the command line. On literally every other service I've used, there's a little box to upload a logo. But Okta have a funny idea of what developers want.

And, to make matters worse, their documentation contains an error! They don't listen to community requests or take bug reports, so I'm blogging in the hope that this is useful to you.

The Command

curl --request PATCH \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer eyJhb...ZEQ' \
  --url 'https://whatever.eu.auth0.com/api/v2/connections/con_qwerty123456' \
  --data ' ... '

You will also need to supply some JSON in the data parameter. I've formatted it to be easier to read than the garbage documentation. All of these fields are mandatory.

{
  "options": {
    "client_id": "your-app-id",
    "client_secret": "Shhhhhh!",
    "icon_url": "https://example.com/image.svg",
    "scripts": {
      "fetchUserProfile": "???"
    },
    "authorizationURL": "https://example.com/oauth2/authorize",
    "tokenURL": "https://example.com/oauth2/token",
    "scope": "auth"
  },
  "display_name": "Whatever"
}

OK, but how do you get all those values?

• Bearer token:
  • Create a management token
  • The only scope it needs is update:connections
• URl
  • This is your normal Auth0 domain name.
  • The Connection ID at the end can be found in the dashboard of your social connection
    
• Client ID & Secret
  • You set these in the social connection's dashboard.
• icon_url
  • Public link to an image. It can be an SVG.
• fetchUserProfile
  • Whatever code you want to run. If you don't want any, you can't leave it blank. So type in a couple of characters.
• authorizationURL and tokenURL
  • Wherever you want to redirect users to
• display_name
  • What you want to show to the user

This is such a load of bollocks! Is it really that hard for the Okta team to put an input field with "type the URl of your logo"?

For a traditional social-media site like Twitter or Facebook, you would create an OAuth app on the service that you want. But there are hundreds of Mastodon servers. So you need to create a new app for each one. That sounds hard, but it isn't. Well… not too hard.

Here's some code adapted from Infosec.press. It's all written using cURL on the command line - so you should be able to adapt it to your preferred programming language.

Register an app on the user's Mastodon instance

Let's assume the user has given you the name of their Mastodon server - example.social

You then send a request for an app to be created on example.social with your website's details. All it requests is the ability to read a user's details, nothing else.

curl -X POST \
 -F "client_name=Login to your_website.tld" \
 -F "redirect_uris=https://your_website.tld/oauth/mastodon?server=example.social&" \
 -F "scopes=read:accounts" \
 -F "website=https://your_website.tld" \
 -A "user-agent/0.1"
 https://example.social/api/v1/apps

You can set the User Agent to be anything suitable. Some servers won't work if it is omitted.

If the request was successful, example.social will send you this JSON in response:

{
  "id": "12345",
  "name": "Login to your_website.tld",
  "website": "https://your_website.tld",
  "scopes": [
    "read:accounts"
  ],
  "redirect_uris": [
    "https://your_website.tld/oauth/mastodon?server=example.social&"
  ],
  "vapid_key": "qwertyuiop-asdfghjkl-zxcvbnm",
  "redirect_uri": "https://your_website.tld/oauth/mastodon?server=example.social&",
  "client_id": "qw_asdfghjkl_zxcvbnm",
  "client_secret": "qwertyuiop1234567890"
}

Save the server's address, the client_id, and the client_secret. You will need all three later.

The user logs in to their Mastodon instance

You need to redirect the user to their server so they can log in. You need to construct a Mastodon URl using the data you received back. Don't forget to URl encode the redirect_uri.

For example, redirect the user to:

https://example.social/oauth/authorize
?client_id=qw_asdfghjkl_zxcvbnm
&scope=read:accounts
&redirect_uri=https://your_website.tld/oauth/mastodon%3Fserver=example.social%26
&response_type=code

When the user visits that URl they can then log in. If they're successful, they'll be redirected back to your server using your specified redirect URI:

https://your_website.tld/oauth/mastodon?server=example.social&code=qazwsxedcrfvtgbyhnujm

Get a Bearer token

Your website has received a GET request with the user's server name and an authorisation code. As per the Mastodon documentation, your app uses that code to request a Bearer token:

curl -X POST \
 -F "client_id=qw_asdfghjkl_zxcvbnm" \
 -F "client_secret=qwertyuiop1234567890" \
 -F "redirect_uri=https://your_website.tld/oauth/mastodon?server=example.social&" \
 -F "grant_type=authorization_code" \
 -F "code=qazwsxedcrfvtgbyhnujm" \
 -F "scope=read:accounts" \
 -A "user-agent/0.1"
 https://example.social/oauth/token

If that's worked, the user's server will return a Bearer token like this:

{
    "access_token": "abcdefg_123456",
    "token_type": "Bearer",
    "scope": "read:accounts",
    "created_at": 1732916685
}

Get the user's details

Finally(!) you can use that token to verify the user's credentials with the server:

curl \
 -H "Authorization: Bearer abcdefg_123456" \
 -A "user-agent/0.1"
 https://example.social/api/v1/accounts/verify_credentials

If that works, you'll get back all the user's details. Something like this:

{
    "id": "7112",
    "username": "Edent",
    "acct": "Edent",
    "display_name": "Terence Eden",
    "url": "https://mastodon.social/@Edent",
    "avatar": "https://files.mastodon.social/accounts/avatars/000/007/112/original/37df032a5951b96c.jpg",
...
}

Putting it all together

1. User providers their Mastodon instance's domain name
2. Your service looks up the domain name in its database
   • If there are no results, request to create a new app on the Mastodon instance and save the returned client_id and client_secret
3. Redirect the User to their Mastodon instance, using a URl which contains the client_id & callback URl
4. User logs in to their Mastodon instance
5. The User's Mastodon instance redirects the User to your service's callback URl which includes an the instance's domain name and User's authorisation code
6. Your service reads the User's domain name and authorisation code
7. Your service exchanges those details for a Bearer token
8. Your service uses the Bearer token to get the User's account details

Next steps?

This basic code works. For my next trick, can I integrate it into Auth0?

You authorise it - whereupon it promptly leaks to the world all your sexts, inappropriate jokes, and dank memes. Tragic!

What's going on?

Many years ago the official Twitter API keys were leaked. This means that app authors who can't get their app approved by Twitter are still able to access the Twitter API.

For some reason, Twitter's OAuth screen says that these apps do not have access to Direct Messages. But they do!

In short, users could be tricked into allowing access to their DMs.

Restrictions

There are some restrictions which Twitter has put in place in the name of good security. The most important of these is restricting callback addresses. After successful login, the apps will only return to a predefined URL. That means you can't take the official Twitter keys and send the user to your app. This is a sensible security decision.

Except... Not every app has a URL. Or supports callbacks. Or is an actual app. Twitter has a secondary authorisation mechanism for such cases. You log in, it provides a PIN, you type the PIN into your app.

It appears that these official PIN apps don't display the correct OAuth information to the user.

Fixing it

Will Twitter audit old apps and make sure the permissions are correctly displayed? I hope so!

Ideally, Twitter should have a much more granular permissions model. Allow apps to read DMs, but not send them. Write tweets, but not delete them. Read Tweets, but not follow people.

Timeline

• 2018-11-06 Submitted via HackerOne
• 2018-11-06 Provided clarification and PoC. Issue accepted.
• 2018-11-15 Proposed publication date of 30th November rejected due to US holidays.
• 2018-11-16 Bug Bounty of $2,940 offered. Filled in the W2 form to say I'm not a US taxpayer.
• 2018-11-17 Drank a fair amount of cider.
• 2018-11-21 £2,287.05 deposited in my UK bank account. There was also the option of receiving it via PayPal.
• 2018-12-06 Twitter fixed the issue and published the bounty payout. They let me know I was clear to publish.
• 2018-12-07 I provided clarification that the issue was still present on some API keys.
• 2018-12-14 Published this report.

You can only sign in with Twitter. That's fine, it's a Twitter product. So I pressed the sign-in button and this is the screen I saw.

Is that the Twitter mobile website embedded into the app or is it a phishing page? I've no way of knowing!

I can't see the URL bar - for all I know, this could be an elaborate forgery. I have to completely trust that this product is actually provided by Twitter. In Periscope's case, it probably is. But this is teaching users a dangerous anti-pattern that the web community has tried so hard to eradicate. And, no, 2FA doesn't really help us here.

Let's take a step back and look at what the problem is.

In the bad old days, if you downloaded a 3rd party app (for Twitter, Facebook, email, etc) the app would ask you for your username and password. This is dangerous. You have no idea what the app is doing with your password. Is it saving it? Selling it to criminals? Silently changing all your settings? Who knows!

So, we introduce a more secure way of doing things, at the cost of a little more complexity.

OAuth

Here's how OAuth works (from a user's point of view - there's a lot more stuff going on in the background!)

1. Click "Log in with Twitter" (or whichever service)
2. Get taken to Twitter's website.
3. Login (if you're not already).
4. Get redirected back to the app
   1. Ideally the redirect automatically logs you in.
   2. In some circumstances Twitter gives you a PIN and says "Type this in to the app"

With OAuth you never need to give up your password to a random app.

It can be slightly cumbersome - especially if you have to remember a 4 digit PIN to complete the login. But I'm strongly in favour of educating users not to give out their passwords willy-nilly.

In Periscope's case, the user has to trust that the app hasn't just ripped-off the Twitter website. There's absolutely no way to verify that it is a genuine and secure login page.

Even if you have 2-Factor Authentication (where Twitter texts you a login code) you're not safe. Why? Because if the app is intercepting your username and password, it can also intercept your 2FA code. Sure, it can only use it for a minute or so (with some restrictions) - but that's enough time to completely take over your account.

As software developers, we have to stop encouraging this anti-pattern. Periscope is teaching users that it's OK to type their password into any box which looks like it's authentic.

Some Solutions

Any solution has to make a user leave the untrusted app and use a trusted service. Sorry, that's just how it is. You can't delegate your trust to an unknown entity.

Here are a few possible solutions - with varying degrees of complexity for the user and programmer.

• Standard web-based OAuth. Take the user to the web where they can check the URL, validate the certificate, see if they're already logged in, etc.
• SMS based OAuth. Type in your username (only!) to the app, receive an SMS with a one-time PIN/Password. It's the equivalent of "Click here to verify your email address."
• Message based OAuth. Type in your username (only!) to the app. Receive a Twitter DM with a one-time PIN/Password. Retrieve the message using your trusted Twitter app or website.
• Use Twitter Digits - only works if the phone number associated with the account is the phone being used.

Look, all of these have a minor impact on how easy it is for a user to sign in. Guess what - so does asking for a password. If we wanted to make sign in nice and easy, we'd just say "Enter your username" and trust that no-one will abuse the system.

We must secure our users and help them to stay secure in the future. Periscope's login model is a retrograde step for user security.

Update!

Here's a video showing the same problem in imgur's new Android app.

Typing your username and password into a third party site is bad idea. A really bad idea. I mean, you may think it's a bad idea to give your bank details to a Nigerian prince but that's just peanuts compared to giving away your password to an untrusted site!

So, that's why we use OAuth. Rather than handing details to a random site, we authenticate against a trusted site which then redirects us back with an authentication token.

That's all well and good on the web, but on mobile apps it becomes a little more difficult.

This is the popular mobile game Temple Run. After dying in the game (as I frequently do!) you can Tweet your score. But, first, you need to connect with Twitter.

However, clicking the button, presents this screen: This is a pop-up within the game. What you see in the screenshot is the totality of what the user sees.

There are now two important questions:

1. How can the user tell if this is the genuine Twitter site?
2. Why is there no indication that the site is served over HTTPS?

This is a clear anti-pattern! We're teaching people to give over their usernames and passwords to sites that appear to be genuine - yet offer no way to validate their legitimacy.

We've been trying to educate people to look at the URL bar - to check that they've visited the correct site and that there's some form of SSL verification (commonly a padlock).

I'm not suggesting that Temple Run is doing anything other than pointing to the correct site. Just that they aren't giving the user a chance to verify the authenticity.

How To Solve This Problem

I haven't the foggiest! Thoughts?

We can't rely on the user having the Twitter app installed and firing via intent (or similar). Due to the huge variety of phones and Operating Systems, there's no easy way (that I know of) to redirect from a website back to the app. There needs to be a way to keep everything in-app to keep the user experience.

So, come on then oh great minds of the Internet, how do we fix this?

Long time readers will know that I have some severe usability and security concerns with Twitter's OAuth implementation. See also my interview in The Register.

Zach Holman has an entertaining and informative blog post about giving Twitter applications fine grained controls.

Essentially, he's saying that you should be able to authorise an app for just posting, for example. Here's his graphic which I've stolen.

This doesn't go far enough.

I was taking a look at this LinkedIn application which graphs your contacts.

Take a look at their OAuth screen.

At the bottom is an "Access Duration" option - giving you the option to try out the app and have it automatically revoke after a specified period of time.

Now, this isn't something you'd want to do for every app. But it gives you a method to limit the damage that a malicious app can do. Remember, just because an app isn't malicious today, doesn't give you any guarantee about its future performance.

As it happens, the Oauth Specification 2.0 has this to say in section 4.2.2. Access Token Response

expires_in OPTIONAL. The duration in seconds of the access token lifetime. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated.

If you run a service relying on OAuth, please consider giving users an Access Duration option.

You can see the full code on Dabr's Google Code page.

First of all, you'll need to have enabled OAuth for your Twitter client. I use Abraham's excellent OAuth libraries for PHP.

This tutorial assumes you already have OAuth working. I'll attempt to explain what I'm doing as I go along - but the code should be pretty readable.

Start by reading the Twitpic API documentation. You will also need to register for an API key - this only takes a few seconds.

We start by setting CURL's headers to those required by Twitpic

//Has the user submitted an image and message?
if ($_POST['message'])
{
    $twitpicURL = 'http://api.twitpic.com/2/upload.json';

    //Set the initial headers
    $header = array(
                            'X-Auth-Service-Provider: https://api.twitter.com/1/account/verify_credentials.json',
                            'X-Verify-Credentials-Authorization: OAuth realm="http://api.twitter.com/"'
                        );

Next, we create the OAuth credentials that we need. Essentially, we're signing a URL request. We then pass that on to Twitpic and they verify it with Twitter. We never pass our OAUTH_CONSUMER_SECRET - so Twitpic can't impersonate us.

    //Using Abraham's OAuth library
    require_once('OAuth.php');

    // instantiating OAuth customer
    $consumer = new OAuthConsumer(OAUTH_CONSUMER_KEY, OAUTH_CONSUMER_SECRET);

    // instantiating signer
    $sha1_method = new OAuthSignatureMethod_HMAC_SHA1();

    // user's token
    list($oauth_token, $oauth_token_secret) = explode('|', $GLOBALS['user']['password']);
    $token = new OAuthConsumer($oauth_token, $oauth_token_secret);

    // Generate all the OAuth parameters needed
    $signingURL = 'https://api.twitter.com/1/account/verify_credentials.json';

    $request = OAuthRequest::from_consumer_and_token($consumer, $token, 'GET', $signingURL, array());

    $request->sign_request($sha1_method, $consumer, $token);

We add these generated credentials into the header.

    $header[1] .= ", oauth_consumer_key=\"" . $request->get_parameter('oauth_consumer_key') ."\"";
    $header[1] .= ", oauth_signature_method=\"" . $request->get_parameter('oauth_signature_method') ."\"";
    $header[1] .= ", oauth_token=\"" . $request->get_parameter('oauth_token') ."\"";
    $header[1] .= ", oauth_timestamp=\"" . $request->get_parameter('oauth_timestamp') ."\"";
    $header[1] .= ", oauth_nonce=\"" . $request->get_parameter('oauth_nonce') ."\"";
    $header[1] .= ", oauth_version=\"" . $request->get_parameter('oauth_version') ."\"";
    $header[1] .= ", oauth_signature=\"" . urlencode($request->get_parameter('oauth_signature')) ."\"";

Add everything into CURL

    //open connection
    $ch = curl_init();

    //Set paramaters
    curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

    //set the url, number of POST vars, POST data
    curl_setopt($ch,CURLOPT_URL,$twitpicURL);

The data we send to Twitpic (message text, image and key) have to go via POST.

    //TwitPic requires the data to be sent as POST
    $media_data = array(
                            'media' => '@'.$_FILES['media']['tmp_name'],
                          'message' => ' ' . stripslashes($_POST['message']), //A space is needed because twitpic b0rks if first char is an @
                          'key'=>TWITPIC_API_KEY
                        );

    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch,CURLOPT_POSTFIELDS,$media_data);

All done, we now send the data to Twitpic.

    //execute post
    $result = curl_exec($ch);
    $response_info=curl_getinfo($ch);

    //close connection
    curl_close($ch);

If this has worked, Twitpic will pass back the URL of the image we posted. We then need to post the entire message to Twitter ourselves (Twitpic can't do it for us).

    if ($response_info['http_code'] == 200) //Success
    {
        //Decode the response
        $json = json_decode($result);
        $id = $json->id;
        $twitpicURL = $json->url;
        $text = $json->text;
        $message = trim($text) . " " . $twitpicURL;

This next part is specific to Dabr - your client may post things differently.

        //Send the user's message to twitter
        $request = API_URL.'statuses/update.json';

        $post_data = array('source' => 'dabr', 'status' => $message);
        $status = twitter_process($request, $post_data);

        //Back to the timeline
        twitter_refresh("twitpic/confirm/$id");
    }

If it didn't work, Twitpic will tell us why.

    else
    {
        $content = "<p>Twitpic upload failed. No idea why!</p>";
        $json = json_decode($result);
        $content .= "<br /><b>message</b> " . urlencode($_POST['message']);
        $content .= "<br /><b>json</b> " . print_r($json);
        $content .= "<br /><b>Response</b> " . print_r($response_info);
        $content .= "<br /><b>header</b> " . print_r($header);
        $content .= "<br /><b>media_data</b> " . print_r($media_data);
        $content .= "<br /><b>URL was</b> " . $twitpicURL;
        $content .= "<br /><b>File uploaded was</b> " . $_FILES['media']['tmp_name'];
    }
}

The easy bit.

It's easy to post the data to Twitpic

$media_data = array(
    'media' => '@'.$_FILES['media']['tmp_name'],
    'message' => html_entity_decode($_POST['message']),
    'key'=>'123465789132465'
);
curl_setopt($ch,CURLOPT_POSTFIELDS,$media_data);

OAuth Credentials

Using Abrahams OAuth library for PHP, it's easy to get the required OAuth data.

require_once('OAuth.php');
// instantiating OAuth customer
$consumer = new OAuthConsumer(OAUTH_CONSUMER_KEY, OAUTH_CONSUMER_SECRET);
// instantiating signer
$sha1_method = new OAuthSignatureMethod_HMAC_SHA1();
// user's token
list($oauth_token, $oauth_token_secret) = explode('|', $GLOBALS['user']['password']);
$token = new OAuthConsumer($oauth_token, $oauth_token_secret);

// signing URL
$fakeurl = 'https://twitter.com/account/verify_credentials.xml';
$request = OAuthRequest::from_consumer_and_token($consumer, $token, 'GET', $fakeurl, array());
$request->sign_request($sha1_method, $consumer, $token);
$OAuthurl = $request->to_url();

The Tricky Bit

I'm following the header example in the API documentation. Passing these variable to Twitpic is where I seem to go wrong.

$header = array(
      'X-Auth-Service-Provider: https://api.twitter.com/1/account/verify_credentials.json',
      'X-Verify-Credentials-Authorization: OAuth realm="http://api.twitter.com/"'
   );

I then modify the second header so it reads

"X-Verify-Credentials-Authorization: OAuth realm="http://api.twitter.com/",
oauth_consumer_key="aaaaaaa",
oauth_nonce="bbbbbbbbbbb",
oauth_signature="ccccccccccccc%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="123456798",
oauth_token="15948715-dddddddddd",
oauth_version="1.0""

The Error

401 "Could not authenticate you (header rejected by twitter)."

GAH!

I wracked my brains thinking about how they could have gotten in there before I realised it was a long-dormant friend who had changed their name and avatar.

But, in thinking about how a spammer could infiltrate one's timeline, I think I came up with a fairly bullet-proof method to spam Twitter users.

I present this as an exercise in devious thinking - and also to show how our assumptions about security can play against us. Remember, hacking and impersonation are likely to be illegal in your jurisdiction.  This information is designed to help you understand how security weaknesses can occur.

Being Evil

Imagine you are a nasty, evil Twitter spammer. Your own mother wouldn't spit on you if you were on fire - that's how mean you are. Here's what you do.

1. Obtain a user's password.  Admittedly, this is the hardest part of the process. You might use a dictionary attack, use the same password they use to log in to another site, or somehow steal it.
2. Log on to Twitter.
3. Go to "Connections" and see which services they have connected to using OAuth.  For the purposes of this experiment, let's assume they use Example.com.
4. Go to Example.com and OAuth yourself with Twitter using your mark's credentials.
5. Here's where the ordinary spammer falls down.  The ordinary spammer will start sending out messages from the mark's account.  That's not the aim of this weakness.
6. From the mark's account, through Example.com, make your victim follow one of your spam accounts.  An account which exists solely to show adverts to your victim.

Your victim now sees your adverts for pills, poker and porn in their timeline.  With any luck, they'll just assume that one of their true friends is promoting your illicit wares.

Counter Attack

Most victims will assume that they accidentally followed your spam account - or that one of their friends has been hacked.

Worst case scenario, they unfollow your spam account.

So you just make them follow you again! Remember, you are still OAuth'd to Example.com. You can make them follow as many of your spam accounts as you think you can get away with.

At this point, the intelligent victim will think that their account may be compromised and change their password.

It doesn't matter! Because you have used OAuth, password changes don't affect you.  You can continue make them follow as many of your spam accounts as you think you can get away with.

At this point, the really intelligent victim will go through their OAuth connections to look for something suspicious.  They won't find it.  Remember steps 3 and 4?  You are OAuth'd to a service that your victim trusts.

Because of the way Twitter displays OAuth information, there's no way for a victim to know when a service was last authorised.

There is no information other than the first time the OAuth was set up.  No last accessed date, no IP addresses, nothing useful.

When following an account, the victim gets no notification of what has happened, when it has happened or how it has happened.  There is no way of them knowing which of their OAuth'd connections have been compromised, nor when it happened.

Their only safe option is to revoke every single OAuth connection.  Then reauthorise.  A time consuming and annoying prospect.

Conclusion

I hope I've demonstrated two things.

Firstly, there's more to spam then just sending out messages.  Forcing someone to read a message is just as annoying.

Secondly, our understanding of security and usability haven't quite caught up with the new tools which are available to us.  OAuth is still better than giving your password to an untrusted site - but without essential usability changes, a compromised account is a lot more dangerous than the user would suspect.

This "attack" still relies on a victim having their original password compromised.  That's not a trivial matter.  But security is like sexual health - it only takes one little accident...

Usually, I would be a big fan of this move - especially if it forces password anti-pattern sites like TwitPic to implement the new, secure standard.

This means that you won't be able to log in to a third party site by giving them your username and  password.  You will have to use OAuth to securely validate with the main Twitter site.

But - as ever - there's a dark side to OAuth.

Repressive Regimes

One of the joys of Twitter is that its clients are decentralised from the main site.

This means that if Twitter is blocked in your country, you can use a third party client (like Dabr) to access it.

Twitter User -> Dabr -> Twitter API -> Dabr -> User

If Dabr became sufficiently popular to be blocked by an oppressive regime, you can switch to any one of the thousands of Twitter web clients.

OAuth forces you to the main Twitter site.  While you may visit Dabr to start with, you would be redirected to Twitter to complete OAuth.  If Twitter is blocked, you can't connect.

At a stroke, Twitter has shut itself off to anyone in a repressive country.

This has been picked up by some concerned users.

A (Hacky) Way Around It

There's really only one way around this problem.  The third party web client has to act as a man-in-the-middle.  There's a patch for Dabr - developed by cnyegle - which will ask for a username and password, then proxy it to Twitter, get the OAuth token and tweet on behalf of the user.

From the user's point of view, they are still giving the (potentially untrusted) site the username and password.

Challenge Response

This could be solved by implemented a challenge / response system.

1. Alice visits the Dabr website.
2. Dabr asks Alice for her username (and only her username)
3. Dabr asks Twitter for the challenge associated with Alice's username.
4. Twitter checks that Dabr is an authorised website (i.e. has signed up for OAuth).
5. Twitter returns the response:  A secret phrase which Alice has previously chosen.
6. Dabr displays this phrase to Alice.
7. Alice knows that Twitter trusts Dabr
8. Dabr asks Twitter for the password challenge.
9. Twitter returns that it requires the 3rd, 5th and last character from Alice's password (the characters requested change randomly).
10. Dabr asks Alice for only those characters.
11. If Alice provides the correct characters, an OAuth token is granted to Dabr to tweet on behalf of Alice.

This has the advantage of proving that Dabr is trusted (by displaying Alice's pre-defined secret phrase) and mitigating the risk that Dabr is untrusted (by only revealing part of the password).

Conclusion

This is a very new area, and I've not had a chance to read through all of the proposals.  Nevertheless, it remains a fundamental problem that, if you can't access a site, you need to delegate your trust to someone else.

I'm not a security expert - so I would appreciate someone pointing out the flaws in my reasoning.

For a service which started out operating by SMS, Twitter takes a surprisingly unenlightened view of mobile. It's main mobile service - http://m.twitter.com/ - is almost completely devoid of useful features. That's one of the main impetuses behind the development of Dabr. Their latest mobile site - http://mobile.twitter.com/ - is really only suitable for the tiny minority of people who have smartphones.

So, understandably, many people use 3rd party sites like Dabr. They are now faced with a dilemma - give an untrusted site their username and password or try to use OAuth on the mobile.

A few weeks ago came the announcement that OAuth was finally ready for mobile... Was it? No. Once again a "mobile friendly" site designed with masses of JavaScript and guaranteed not to work with the majority of phones on the market.

Here's how mobile OAuth looks on a variety of popular mobile phones.

BlackBerry

BlackBerry Twitter OAuth

While this looks pretty enough, it doesn't work. The buttons aren't clickable. I've tried with and without JavaScript. No matter where I click, nothing happens.

Android

The Android's User-Agent isn't detected by Twitter as being a mobile phone. While it's true that the browser is very capable - the OAuth screen is a lot more usable when it's in mobile mode.

Android Twitter OAuth

So, it works, but it doesn't look nice.

N95

The N95 makes a good test phone because it's popular. Probably more popular than the iPhone.

N95 Twitter OAuth

N95 Twitter OAuth

It's not pretty - but at least it works.

Others

The Sharp GX-10 is my default test phone. One of the first phones with a colour HTML browser. If your site can work on this phone, it will work on any phone. There are no screenshot capabilities for this phone - but rest assured, it does not work.

The three phones I've demo'd above are very popular modern phones - AKA the minority. If they don't work well, what chance for the people using older phones?

Useless! How hard can it be? All it needs is a username field, a password field and a button. That's just about the most basic page imaginable. It should be child's play to make it work on mobile.

This was first raised in March 2009 on Twitter's issues list. It's currently the most popular bug.

So, we're stuck in a dire situation. Third-Party mobile sites get access to Twitter users' passwords because Twitter are unable or unwilling to develop a simple OAuth form. It would be fascinating to know how many of Twitter's security breaches are down to corrupt or insecure 3rd party sites which leak passwords.

I received a rather worrying email from Twitter.  Apparently they thought my password had been compromised and needed to be reset.

Reset Your Twitter Password

After checking to see if it was valid, I went and changed my password.  Any site which relied on a cookie to post to Twitter would have been blocked out. Ha! Gotcha, suckers!

The OAuth Problem

OAuth tokens are not revoked when the master password is changed.

OAuth is a great idea - rather than give your username and password to any random site, you log on to Twitter and tell them that you authorise the refering site.  The site gets an OAuth token and never gets to see your password.  Great! Right? Not really.

Let's consider the following scenario.

Alice has a Twitter username and password.

Bob runs a Twitter site.

Alice visits Bob's site.  Alice is security conscious and uses OAuth.

Eve somehow discovers Alice's password.

Eve also visits Bob's site and uses OAuth.

Alice gets suspicious about strange activity on her account and changes her password.

Because Bob's site uses OAuth, it does not require either Alice or Eve to re-enter Alice's password.

In this scenario, Alice has to visit Twitter's OAuth Connections page and revoke access to all the sites she has previously connected to.  Alice has no way of knowing when each site was last accessed.  She also doesn't know which site Eve is using.

Twitter's OAuth Page

The Problem

Changing a password should - in the minds of most people - mean that you need to re-enter your password even if you have previously authenticated yourself.

In this scenario, changing the password does not revoke access to malicious users who have previously used your credentials.

Twitter should revoke all OAuth tokens when a user's password is changed. It is the only way to ensure that stolen credentials cannot continue to be used after a user has changed their password.

Addendum

As I've made clear in the comments - this isn't a vulnerability within OAuth per se.  It's a usability issue which has strong security implications.

I spoke to Eran Hammer-Lahav (listed as OAuth's advisory contact) who said:

If you suspect someone stole your password, you should revoke any tokens you did not personally authorized. But there is no reason to revoke tokens just because you are changing password.

While I appreciate this as the official line from those in the know, it does nothing to prevent a user who uses the same sites as you.  For example, I can see on every tweet that you use Dabr.  Therefore, I can safely OAuth myself as you on Dabr.  You'll change your password, but you won't revoke Dabr's token because you personally authorised it.

Continuing The Conversation

Heise Online provides comentary in German (English version)

El Reg has a feature about Twitter and OAuth.

There's also an interesting discussion over at Hacker News.