OAuth2 implicit (client) flow

[Alexey Zakharov]

From GTM docs:

>> Each service will provide developers with Client ID and Client Secret strings intended to be hardcoded as constants into applications.

I currently don't understand why this info is shared on client side. The right way is to use client side flow. It is describe in facebook oauth2 docs: http://developers.facebook.com/docs/authentication/

Sharing client id and secrete on devise is insecure. Are you going to fix it in future or not?

[Greg Robbins]

Facebook's current authentication does not yet match the latest OAuth 2 spec.

The client ID and secret that are included in native apps are understood by the server to not be genuine secrets.

Google's OAuth 2 implementation includes an extension to the standard specifically to more securely support native apps, described at http://code.google.com/apis/accounts/docs/OAuth2.html#IA

[Roberto Tyley]

I'm trying to get a handle on this, forgive me:

On Friday, September 2, 2011 1:14:39 AM UTC+1, Greg Robbins wrote:

The client ID and secret that are included in native apps are understood by the server to not be genuine secrets.

Does the server distinguish between client IDs&secrets that are allocated to native clients vs server apps?

 

Google's OAuth 2 implementation includes an extension to the standard specifically to more securely support native apps, described at http://code.google.com/apis/accounts/docs/OAuth2.html#IA

The description there talks about using the special redirect uri of urn:ietf:wg:oauth:2.0:oob to cause the authenticating service to show a copy-and-pastable authorization code - but also goes on to specify the native client should make a request for an access token using client_secret. Has adding the copy-and-paste step made the exposure of client_secret okay? Could a malicious web application take those credentials and re-use them in a different context with a non-oob redirect url?

I think I still haven't got a handle on the issues around client impersonation. The latest version of the OAuth spec says:

The authorization server MUST authenticate the client whenever
   possible.  If the authorization server cannot authenticate the client
   due to the client's nature, the authorization server MUST require the
   registration of any redirection URI used for receiving authorization
   responses, and SHOULD utilize other means to protect resource owners
   from such malicious clients.  For example, the authorization server
   can engage the resource owner to assist in identifying the client and
   its origin.

This seems to imply to me that the authorization server does need to distinguish between client IDs&secrets that are allocated to native clients vs server apps.

Any comments much appreciated,

Roberto

[Greg Robbins]

Google's server does distinguish between installed and native app registrations. When an installed application signs in, the server will not redirect to another site following sign-in. 

When signing in with an installed application client ID, the native application must intercept and interpret the window title set by the server, or the user must manually copy and paste the access token. A web application cannot do those, so a web app cannot use an installed application's client ID

OAuth 2 was designed primarily for web applications. In general, as installed applications can be inspected, there is not a reliable way to put secrets into any installed app. It is more accurate to think of the OAuth 2 client secret for installed apps as just being an extension of the client ID; it is not really a secret.

It is routine among OAuth 2 providers to require registration of redirect URIs. Google's "oob" URI and specific handling of installed applications is an attempt to do a bit more to separate how registered installed applications sign in.