Google has announced that they are sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November 2014. SHA-1 root certificates are not affected by this plan.
Most providers are offering free upgrades to SHA-2 certificates so be sure to contact yours to see if you qualify.
First off, ensure that you have registered your application with Google and have created the following in your settings file:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The first step in the oauth handshake is to redirect to Google with some application specific data in the URL including your client ID, scope (what data you want access to) and redirect URL (where you want Google to send the user after they’ve approved / denied the application)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This url can now be used to redirect to Google (i.e. HttpResponseRedirect(url)):
3) Handle the response (approved or denied)
Once the user makes their choice to approve or deny, Google will redirect back to your redirect_url. You will need to verify the user approved the application:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
If any of the above tests fail, we can safely assume the user either arrived at this page directly (i.e. by typing in the URL) or they denied the application. Either way we don’t want to proceed and should redirect them to the start of the registration flow (i.e. HttpResponseRedirect(reverse('register'))).
4 & 5) Get an access token and the user’s profile
At this point the user has authorized your application but you don’t have actual access to their data yet. To get that you’ll need to request an access token. Notice that we’re saving the access token to the user’s session as we don’t want to request it more than once during the registration flow.
Once you have the access token, you can then make the request for the user’s profile data:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
That’s it! You can now use the user’s profile information to pre-fill a registration form, perhaps skipping over fields where you already have a required value such as an email address or first and last name. Just be sure to save their Google ID along with their profile so you can use it validate them in the future. You should also save the access_token and expires values so that you can make future requests to the API for this user or refresh the access token when it has expired.
In a future post I’ll be looking at how to detect an already registered user as well as provide a login with this provider button.