Are you using approval_prompt=force?

The recent launch of incremental auth has highlighted a couple of problems in the way some sites have implemented Google+ Sign-In or Google OAuth 2.0. The most obvious of these is that there are a fair number of places that use approval_prompt=force much more often than they should, which leads to a much worse user experience than there needs to be.

What’s the problem

Several sites set approval_prompt to force either in the Javascript Google+ Sign-In button (where it is generally approvalprompt), or in a parameter in the auth URL as part of a redirect based flow. This parameter means that users have to see the consent screen even if they had previously granted access to the application for the requested scopes.

While this was never a great user experience, the recent release of incremental auth has made it even more visible. Because the user has granted access before, they are not shown most scopes. However, because force is specified, they have to be shown a consent dialog. The only reason to show a consent dialog when the user has consented previously is to get a code that can be exchanged for a new refresh token - used primarily for offline access. Therefore the consent dialog displays that the app is requesting to "Have offline access" only.

This looks pretty weird! If you want to try it yourself, there is a small demo below.

There are two main reasons (that I'm aware of) why people do this:

  1. Its a copy and paste from an example
  2. To stop immediate mode auth from firing and signing the user in when the button displays

The second is a concern for people implementing the Javascript sign in flows, and usually is seen with a site sign-out feature. For example, you might try to log people out by deleting the application cookie, but then see them immediately signed-in again due to the immediate mode check when rendering the sign-in button. The best way to resolve this issue is to use gapi.auth.signOut when you log the user out. This sets local state that prevents the immediate mode check from signing the user in, and allows you to display the button appropriately.

In the first case where it is just came that way, simply remove the parameter and users will be able to sign in without seeing another consent dialog.

When should I use force

Forcing the approval prompt should only be used when you need to acquire a new refresh token. For example, if a user signed-in but their refresh token stored server side is no longer valid (perhaps it was accidentally deleted), you may want to pop up a dialog to say “we lost access to your [Google Service Here], please sign-in to re-enable”. At that point you can pass force in order to force a consent dialog to appear, and to get a code that returns a refresh token when exchanged.

Any questions about this, feel free to leave in the comments!

Popular posts from this blog

Client-Server Authentication with ID tokens

Image
These days there are few purely client-side applications - even traditionally unconnected software like casual games make use of servers and services to provide a better, richer experience - and importantly one that can follow the user across devices. We are in a world where we need to authenticate a user of many clients to a set of back-end services. There are a few ways of doing that when using a identity provider, like Google, but in this post I want to talk about a specific method that makes use of ID tokens. This approach has been well covered by Tim Bray for Android, but with the release a couple of months ago of the iOS 1.4.0 SDK for Google+, it is now available across Android, iOS and the Web. This makes it a particularly powerful way of signing in a user, and asserting the identity of that user securely to your application servers. Why ID TokensThis whole architecture relies on a point of view which I suspect is still not particularly common amongst developers implementing au…
Read more

Common problems with Google+ Sign-In on Android

Image
It has been fantastic to see so many people trying out Google+ Sign-In, and through the bootcamps and other events I've had a chance to talk to some people who are actually implementing it in their apps. The Android integration is pretty straightforward, thanks to Google Play Services, but there are still some issues I've seem come up a couple of times.

tl;dr: make sure your app is set up in the API console, and make sure you can handle multiple onStart events coming in during sign-in.

1. Consent screen appears more than once. 

The basic life cycle of the PlusClient looks a bit like this:


When we call the onStart, we immediately call mPlusClient.connect(). Google Play Services checks whether the user is already signed in to the application, and, if so the onConnected method is instantly called and the user seamlessly signed in.

If the connect() call fails, then onConnectionFailed() is called with a ConnectionResult object, which represents the error. The error is probably RESOLU…
Read more

TLS and ZeroMQ

It's pretty straightforward to use synchronous encryption over ZeroMQ - just a case of encrypting and decrypting at each end with some previously shared key. Asynchronous encryption is a bit more interesting, as it allows signing for message integrity and authenticity, as well as data hiding. There have been some good examples of crypto over Pub/Sub (notably Salt), but not a lot of examples of direct messaging.

The de-facto library for this sort of work is OpenSSL, but this has a couple of problems. The first is that usually openssl manages the TCP connection itself, which could be an option for some ZeroMQ cases, but doesn't fit if the user wanted to use a different transport, or an unusual topology. TLS or SSL also require a handshake at the start of the communication, which means we may have to send messages back and forth without there being any application data.

For the first part, OpenSSL includes support for usage as a filter thanks to it's BIO IO abstraction layer.…
Read more