Oauth/access_token Stopped working today

[garrettmurray]

Building an app that has been working for 3 months now, up to and including last night. No changes made to any code, but today I cannot successfully use oauth/access_token. I receive error 401:

<?xml version="1.0" encoding="UTF-8"?> /oauth/access_token Invalid / expired Token

As I said, I have not changed anything and this worked as of 3AM last night. What’s going on?

Solution here: In my reply below: https://dev.twitter.com/discussions/16443#comment-36618

[manton]

I noticed the same thing today. At first I assumed it was something with the 1.1 change in my code (made a few weeks ago), but I spent a couple hours debugging and everything is correct except the 401 from Twitter. And auth was working perfectly fine before today – it’s a web app that launched a year ago.

[garrettmurray]

@manton Just figured it out! Turns out during the oauth/access_token request, you MUST pass oauth_verifier now. Switch seems to have been flipped in the last 2 days. From the docs, though, it seems this shouldn’t be required yet:

For OAuth 1.0a compliance this parameter is required unless you are using xAuth. Currently Twitter supports both OAuth 1.0 and OAuth 1.0a which means we do not error if this value isn't included. It is strongly recommended that applications not using this parameter are immediately updated with support for oauth_verifier added. OAuth 1.0a will be enforced soon and applications not using the oauth_verifier will fail to complete the OAuth flow.

So even though it says “will be enforced soon” it turns out soon is NOW. I added the verifier and it worked.

[simondlr]

Same here. It just broke. Rather frustrating.

[totombola]

Can you point me to the documentation for this?
I get oauth_token, oauth_verifier, but not oauth_token_secret, how can I use the oauth_verifier?

[manton]

Thanks Garrett! I had always been passing the verifier parameter but it turns out I had the name misspelled – auth_verifier instead of oauth_verifier. Fixed the typo and everything works again.

[episod]

Hi folks,

We did in fact flip the enforcement bit on this – I’ll update the doc to reflect.

There are two aspects to the change – both are mandatory parts of the OAuth 1.0A spec that we’ve been lenient with in the past:

• You must pass an oauth_callback value to oauth/request_token. It’s not optional. Even if you have one already set on dev.twitter.com. If you’re doing out of band OAuth, pass oauth_callback=oob.

• You must pass along the oauth_verifier you either received from your executed callback or that you received hand-typed by your end user to oauth/access_token.

• Additional reminder: Scraping a PIN code/oauth_verifier from the HTML page that displays it in out of band OAuth is very very uncool.

[BootMask]

Hi there, I use https://github.com/abraham/twitteroauth and the app has also stopped working. What changes are needed in this library, or would it be in the app using the library itself that must be updated?

[BootMask]

Update, I fixed my issue - I was in fact receiving ‘oauth_verifier’ back from twitter. My app was trying to collect this value via $_REQUEST Once I changed this to $_GET[‘oauth_verifier’] bingo it started working.

[ysekand]

Thanks for letting us know in advance and certainly thanks for updating the documentation in a timely manner.

A big thank you from all my users who haven’t been able to sign in to their favorite web app for the last 24 hours.

Also a big thank you for wasting over 5 hours of my time trying to identify the issue.

Thank you.

[The_Tick]

Could you guys introduce a policy that you do not change what is enforced in the api unless it has both been documented and announced for $N amount of time? That’d be the polite thing to do.

[abraham]

$_REQUEST should work fine. I’m even using it in the example code.

https://github.com/abraham/twitteroauth/blob/master/callback.php#L23

[episod]

We wouldn’t make changes to the OAuth flow without notice unless we felt it was necessary.

[georgeludwig]

This is a big mess for me. I’ve now got a couple of hundred users who cannot log in to my app, and my oauth library (oauth.signpost) apparently does not support submitting a callback URL along with a verifier. I may need to swap out the library entirely.

In the meantime, I’m up to my lower lip with work related to different high priority project. My day, and likely the rest of my week, is completely frakked as a result of this.

Seriously, a little heads-up would have been appropriate.

[garrettmurray]

I think the issue in this case was that the documentation said it was optional and would change in the future, but the change was made without warning and it became required, but without doc updates, it was hard to find.

I understand that you guys felt it was necessary, but since it was previously optional I’m sure it broke a lot of stuff and no one even mentioned it anywhere after the change was made.

[chris_radcliff]

Not to pile on, but I was also affected by this today. A quick note to @twitterapi or on the blog, even after the fact, would have saved me the effort of chasing down a mysterious fault in known-working code.

“After the fact” includes now. It isn’t too late to notify all the developers who will discover this later than we did.

[BootMask]

Hi @abraham thanks for replying! Good to know thanks for clarifying

[jedsundwall]

+1

[air_dex]

“Additional reminder: Scraping a PIN code/oauth_verifier from the HTML page that displays it in out of band OAuth is very very uncool.”

That thing could be easily avoided with convenient endpoints. If there were endpoints which sends back the OAuth informations in a convenient format like “oauth_verifier=theVerifier&…” or the same thing in JSON ("{ “oauth_verifier” : “theVerifier” , …}"), Twitter Developpers would not attempt to parse your (unusuable) HTML pages.

There are lots of developers who get different needs than yours and who have to deal only with endpoints made for your needs. If these developers get convenient endpoints, such reminder will be useless.

[episod]

That defeats the purpose of the oauth_verifier – it’s to signify that the end user in fact participated in the act and that it wasn’t simply automated through an application’s knowledge of the username and password. Any access tokens obtained through this means could not be seen as a valid representation of the user’s communicated, explicit intent.