Migración de OAuth1 3L a OAuth2:

Estoy tratando de migrar tokens OAuth1.0 3L existentes a OAuth2.0 para una aplicación web. Estoy siguiendo las instrucciones enhttps://developers.google.com/accounts/docs/OAuth_ref A pesar de todos mis esfuerzos, sigo recibiendo esta respuesta: "Encabezado de autorización no válido".

Para crear el encabezado de Autorización, uso la biblioteca de cliente Java 1.0 de Google, la misma que uso en la aplicación para hablar con Google Calendar. Estoy probando con un token de acceso. secreto de token, clave de consumidor y secreto de consumidor que funcionan sin problemas (es decir, puedo usar estas credenciales para realizar llamadas a Google Calendar, etc.).

Este es el código que uso:

    OAuthParameters oauthParameters = new OAuthParameters();
    oauthParameters.setOAuthConsumerKey("www.mywebsite.com"); // this is the same consumer key used by my app normally, without problem. mywebsite is an example, the real name is different
    oauthParameters.setOAuthConsumerSecret("XXXXX");
    oauthParameters.setOAuthToken("YYYYY");
    oauthParameters.setOAuthTokenSecret("ZZZZZZ");

    OAuthHmacSha1Signer signer = new OAuthHmacSha1Signer();
    OAuthHelper oauthHelper = new GoogleOAuthHelper(signer);
    String requestUrl = "https://accounts.google.com/o/oauth2/token";
    String header = oauthHelper.getAuthorizationHeader(requestUrl, "POST", oauthParameters);
    String payload = "grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Amigration%3Aoauth1&client_id="+clientId+"&client_secret="+clientSecret;

    HttpClient httpClient = new DefaultHttpClient();

    HttpPost httpPost = new HttpPost(requestUrl);
    httpPost.addHeader("Authorization", header);
    httpPost.addHeader("Content-Type", "application/x-www-form-urlencoded");
    httpPost.setEntity(new ByteArrayEntity(payload.getBytes()));
    String response = httpClient.execute(httpPost, new BasicResponseHandler());

y este es el rastro de cable producido por HttpClient:

>> "POST /o/oauth2/token HTTP/1.1[\r][\n]"
>> "Authorization: OAuth realm="", oauth_signature="ixVbjINI6pgPU2RqXGiQRbPGY%3D", oauth_nonce="486642280771700", oauth_signature_method="HMAC-SHA1", oauth_consumer_key="www.mywebsite.com", oauth_token="YYYYY", oauth_timestamp="1395127834"[\r][\n]"
>> "Content-Type: application/x-www-form-urlencoded[\r][\n]"
>> "Content-Length: 193[\r][\n]"
>> "Host: accounts.google.com[\r][\n]"
>> "Connection: Keep-Alive[\r][\n]"
>> "User-Agent: Apache-HttpClient/4.3.2 (java 1.5)[\r][\n]"
>> "[\r][\n]"
>> "grant_type=urn%ietf%params%oauth%grant-type%migration%oauth1&client_id=12345&client_secret=ABCDE"
<< "HTTP/1.1 400 Bad Request[\r][\n]"
<< "Cache-Control: no-cache, no-store, max-age=0, must-revalidate[\r][\n]"
<< "Pragma: no-cache[\r][\n]"
<< "Expires: Fri, 01 Jan 1990 00:00:00 GMT[\r][\n]"
<< "Date: Tue, 18 Mar 2014 07:30:39 GMT[\r][\n]"
<< "Content-Type: application/json[\r][\n]"
<< "X-Content-Type-Options: nosniff[\r][\n]"
<< "X-Frame-Options: SAMEORIGIN[\r][\n]"
<< "X-XSS-Protection: 1; mode=block[\r][\n]"
<< "Server: GSE[\r][\n]"
<< "Alternate-Protocol: 443:quic[\r][\n]"
<< "Transfer-Encoding: chunked[\r][\n]"
<< "[\r][\n]"
<< "5a[\r][\n]"
<< "{[\n]"
<< "  "error" : "invalid_request",[\n]"
<< "  "error_description" : "Invalid authorization header."[\n]"
<< "}"
<< "[\r][\n]"
<< "0[\r][\n]"
<< "[\r][\n]"

donde 12345 y ABCDE son obviamente marcadores de posición para las credenciales reales de la aplicación OAuth2.

He verificado doble y triplemente que todos los parámetros establecidos en OAuthParameters son los mismos utilizados por el código normal que actualmente funciona usando OAuth1 (incluso usando un depurador paso a paso para verificar los valores en el momento en que OAuthHmacSha1Signer calcula la firma .getSignature ()).

Observé el encabezado de Autorización en las solicitudes HTTP enviadas por las API actuales de clientes de Google que usan OAuth1 (y eso funciona bien), y aparte de la firma, nonce y marca de tiempo, se ven idénticas a las enviadas por esta llamada de migración.

Incluso probé una solicitud de migración de prueba, que falló, luego usé un depurador para ejecutar el código antiguo y el método de inyección, URL, nonce y marca de tiempo utilizados por la llamada de migración, y la firma calculada por el código antiguo era idéntica, dados parámetros idénticos.

¿Alguna pista de por qué el encabezado de autorización todavía se informa como no válido?

Respuestas a la pregunta(3)

Su respuesta a la pregunta