1
votes

Is it possible to migrate oauth1 3lo access tokens and secrets to oauth2 refresh tokens?

We have some customers who were authenticated by 3-legged auth. So we have their access tokens and secrets which work for old api now and these customers don't have installed oauth2 applications to their domains(they can do not have google domains at all). We used our old oauth1 application for 3-legged auth which is being migrated to GAMv2.

We want to convert these tokens to oauth2 refresh tokens as https://developers.google.com/accounts/docs/OAuth_ref describes, but it doesn't work - for different oauth2 test applications we get different messages: (We used Signed-request flow for migration)

1) { "error" : "unauthorized_client" }

Valid client_id and client_secret are used, from cloud console. It looks like client_secret is wrong, but we rechecked and used different applications - the same issue.

2) We have a test web oauth2 application with the error: { "error" : "disabled_client", "error_description" : "The OAuth client was disabled." }

OAuth2 application works properly, so we don't understand what does it mean.

There is How does one migrate from OAuth 1 2LO to OAuth Domain-Wide Delegation For Google APIs?

but this question describes other case: 2lo -> domain.

Hi Miguel!

My request is

POST /o/oauth2/token HTTP/1.1

Authorization: OAuth realm="", oauth_signature="iaiTn9C0nCU5LpZrdOtusDEZGMk%3D", oauth_nonce="103474114541826", oauth_signature_method="HMAC-SHA1", oauth_consumer_key=".apps.googleusercontent.com", oauth_token="1%2F9xOzJNN4Dk2OmEyiRc-", oauth_timestamp="1385471501"

Content-Type: application/x-www-form-urlencoded

Content-Length: 161

Host: accounts.google.com

Connection: Keep-Alive

User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Amigration%3Aoauth1&client_id=.apps.googleusercontent.com&client_secret=iJneLhCLJv

Response is

HTTP/1.1 400 Bad Request

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: Fri, 01 Jan 1990 00:00:00 GMT

Date: Tue, 26 Nov 2013 13:25:11 GMT

Content-Type: application/json

X-Content-Type-Options: nosniff

X-Frame-Options: SAMEORIGIN

X-XSS-Protection: 1; mode=block

Server: GSE

Alternate-Protocol: 443:quic

Transfer-Encoding: chunked

{ "error" : "disabled_client", "error_description" : "The OAuth client was disabled." }

And other type of response is

HTTP/1.1 400 Bad Request

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: Fri, 01 Jan 1990 00:00:00 GMT

Date: Tue, 26 Nov 2013 13:27:02 GMT

Content-Type: application/json

X-Content-Type-Options: nosniff

X-Frame-Options: SAMEORIGIN

X-XSS-Protection: 1; mode=block

Server: GSE

Alternate-Protocol: 443:quic

Transfer-Encoding: chunked { "error" : "unauthorized_client" }

1
Could you provide a sample of the failing requests? (of course, without including client_secret & token).Miguel Andres
Hi Miguel! I updated my question with http request and responsesKirill
Thanks, will look closer into this and let you know my findings.Miguel Andres

1 Answers

0
votes

The problem is in the client validation specified in the migration docs (your consumer type - native - does not match your client type - web).

We have made some changes in our end to solve this issue, could you check again and confirm whether or not the problem persists?