So the world was shocked recently when the new OAuth draft spec came out, and it was completely different from OAuth 1. It’s a much better spec overall, but still there’s a lot of work that has gone into the 1.0 implementations.
But then it occurred to me that since 1.0 and 2.0 have almost no overlap, there’s no reason why one has to obscure the other. So right now, I’m treating OAuth as an extention to 1.0 that adds a Bearer Token protocol to the original spec. We can support that.
Right now, internally, we’re only using 2-legged OAuth anyway. And the work I need to do on the Bearer Token scheme will, ironically, add the pieces that I’m missing for a complete 1.0 3-legged implementation.
So once I started thinking of it that way, it reduced the angst over spec drift greatly.
Currently my biggest grief comes from how much detection I want to do, because I could certainly walk through the protocols and, for example, upgrade from an Oauth 2 Bearer Token to an OAuth 1 3-legged request.
Now my grief is coming from the architecture guys — someone has decided that he wants an implementation that’s “more lightweight” than what I developed (even though I told them for months what I was going to do, did it, scored a couple of HUGE wins with it, etc.). So right now my plan is to open-source the core classes of my implementation, then just wait for someone to show up and cut my throat. But, hey, that’s life in the big city.