Keep getting error=unsupported_response_type

[Mihir]

I am trying to use Oauth 2.0 for client side to authenticate from a mobile device so i can retrieve their Google analytics data. 

I first make the following call - 

https://accounts.google.com/o/oauth2/auth?response_type=token&client_id=1061012813065.apps.googleusercontent.com&redirect_uri=http://localhost&scope=https://www.googleapis.com/auth/analytics.readonly&approval_prompt=auto

Note - the login window, doesn't say anything about the application requesting access, it's simply a google login window - not sure if that's correct but anyways - 

Once I login successfully my browser is re-directed back to http://localhost/#error=unsupported_response_type

I've been following the instructutions here:

http://code.google.com/apis/accounts/docs/OAuth2UserAgent.html

What am I doing wrong or is the API still experimental as it says and something not working? 

Thanks,

Mihir

[Marius Scurtescu]

Hi,

The user-agent flow (response_type=token) is meant for JavaScript
applications running in a browser. This flow will issue only an access
token.

For an application running on a mobile device (aka installed app or
native app) you probably want to get a refresh token so you should
request an authorization code first and then swap it. For this flow
use response_type=code.

Does that work for you?

Marius

[Mihir]

The application is built using phonegap and it's all running in a
webview hence I decided to go this route. Are you saying it won't be
possible to use this unless it's actually running in a desktop
browser?

Thanks,

M

On Dec 8, 4:20 pm, Marius Scurtescu <mscurte...@google.com> wrote:
> Hi,
>
> The user-agent flow (response_type=token) is meant for JavaScript
> applications running in a browser. This flow will issue only an access
> token.
>
> For an application running on a mobile device (aka installed app or
> native app) you probably want to get a refresh token so you should
> request an authorization code first and then swap it. For this flow
> use response_type=code.
>
> Does that work for you?
>
> Marius
>
>
>
>
>
>
>
> On Thu, Dec 8, 2011 at 4:01 PM, Mihir <mihir.ma...@gmail.com> wrote:
> > I am trying to use Oauth 2.0 for client side to authenticate from a mobile
> > device so i can retrieve their Google analytics data.
>
> > I first make the following call -
>

> >https://accounts.google.com/o/oauth2/auth?response_type=token&client_...

[Marius Scurtescu]

On Thu, Dec 8, 2011 at 4:44 PM, Mihir <mihir...@gmail.com> wrote:
> The application is built using phonegap and it's all running in a
> webview hence I decided to go this route. Are you saying it won't be
> possible to use this unless it's actually running in a desktop
> browser?

I am not familiar with phonegap, not sure what features it offers. You
should be able to use the flow I suggested with a webview on a phone.
Can you control the authorization request and ask for code instead of
token?

Marius

[Mihir]

Yes, If I change the response_type to token then the flow seems to
work fine and I understand that I can use the query string parameter
to get the access and refresh tokens etc. Although this whole
javascript is running in the webview of the mobile browser and based
on the documentation, what I am trying to do with response_type=token
should also work in the same fashion ..no?

I am trying to avoid storing the application secret on the phone.
Based on my understanding if I used request_type=token I wouldn't need
to store the client secret nor have to worry about maintaining the
refresh tokens etc.

Anyways, Thank you for your help and input. I think i'll go the
regular installed application route but I was hoping I wouldn't have
to :)

Thanks,

Mihir

On Dec 8, 4:50 pm, Marius Scurtescu <mscurte...@google.com> wrote:

[Marius Scurtescu]

On Thu, Dec 8, 2011 at 5:10 PM, Mihir <mihir...@gmail.com> wrote:
> Yes,  If I change the response_type to token then the flow seems to
> work fine and I understand that I can use the query string parameter
> to get the access and refresh tokens etc. Although this whole
> javascript is running in the webview of the mobile browser and based
> on the documentation, what I am trying to do with response_type=token
> should also work in the same fashion ..no?
>
> I am trying to avoid storing the application secret on the phone.
> Based on my understanding if I used request_type=token I wouldn't need
> to store the client secret nor have to worry about maintaining the
> refresh tokens etc.
>
> Anyways, Thank you for your help and input. I think i'll go the
> regular installed application route but I was hoping I wouldn't have
> to :)

If you provide a good reason to use the token flow on a phone then
maybe we can relax this condition.

If the token flow was used, you would receive only an access token.
When this token expires, how is the application getting a new one? If
it sends the user through the same flow then the approval page will
not show up, but the login page probably will. If the webview is
closed and then re-opened then I assume the cookie jar is gone, so the
user has to login again.

Don't worry about storing the client secret on the phone. Since this
is a native app client it is well understood that the secret cannot be
protected in this case.

Marius

[Mihir]

Well when the token expires, I would kick off the flow again. Assuming
the user has chosen to stay signed into to google and since the
webview is programmatically opened and closed, I can make the process
of obtaining new token completely transparent to the user.

In case when they choose not to stay signed in - yes they would have
to sign in everytime (not necessarily authorize the app).

I've tested my theory on iPhone and it works - as in google keeps
returning me the unsupported response type without asking me to login
even between app restarts. My app monitors the url of the webview so
if I get the access token successfully the webview could stay hidden
and I can do use the access token (without the user even noticing that
I got the access token). I can always show the webview (which will
most likely ask the user to login to google) if something went wrong.

I agree, if I went the normal oauth route I wouldn't have to rely on
needing the user to stay logged into google or login to google
everytime but for my usecase that's not a big deal. (Also most users
are almost always logged into google/fb anyways so using webview to
get access token for an app they've authorized already seemed just
quick and easy)

-Mihir

On Dec 8, 5:21 pm, Marius Scurtescu <mscurte...@google.com> wrote:

[Breno de Medeiros]

On Fri, Dec 9, 2011 at 17:09, Mihir <mihir...@gmail.com> wrote:
> Well when the token expires, I would kick off the flow again. Assuming
> the user has chosen to stay signed into to google and since the
> webview is programmatically opened and closed, I can make the process
> of obtaining new token completely transparent  to the user.
>
> In case when they choose not to stay signed in - yes they would have
> to sign in everytime (not necessarily authorize the app).
>
> I've tested my theory on iPhone and it works - as in google keeps
> returning me the unsupported response type without asking me to login
> even between app restarts. My app monitors the url of the webview so
> if I get the access token successfully the webview could stay hidden
> and I can do use the access token (without the user even noticing that
> I got the access token). I can always show the webview (which will
> most likely ask the user to login to google) if something went wrong.
>
> I agree, if I went the normal oauth route I wouldn't have to rely on
> needing the user to stay logged into google or login to google
> everytime but for my usecase that's not a big deal. (Also most users
> are almost always logged into google/fb anyways so using webview to
> get access token for an app they've authorized already seemed just
> quick and easy)

It's even simpler to use the code flow and store the refresh_token,
since you can renew the token without a webview at all.

--
--Breno

[Allan Medeiros]

Hi,

  I know this is an old message but I was having the same problem as Mihir and I only can use access code istead of token in the code parameter.

The problem is that I need to fetch user information for my iphone app, and for that I need an access TOKEN not a CODE.

How can I overcome this problem? (get a token OR get user information with a CODE)?

Thank you all for any help!

[]'s