English ▼
Skip to page content Skip to main navigation
e.g. "templates" or "datastore"

# Configuring Your App's Authentication

Marzia Niccolai
August 2008

Updated by Rufus, June 2011. Updated by Matthew Blain, October 2011.

## Introduction

With Google App Engine, you can use Google Apps to:

1. restrict your application to members of your domain
2. deploy your application to any domain you own

In the next article, we discuss how to deploy your application on a custom domain. Below, we discuss the available authentication options, and how to select the correct one for your application.

## App Engine authentication options

Google offers three different systems for authenticating your application's users. Only one form of authentication can be used for a given application.

- Google Accounts

  Google Accounts is Google's unified sign-in system. All a user needs is a valid email address (it doesn't need to be a Gmail address!) to sign up for a Google Account. This also includes Google Apps accounts which have transitioned to the new Google Apps infrastructure.

- Google Apps Accounts

  Users of Google Apps for your domain can choose to restrict all or part of their web application to only those people who have a Google Apps account managed by their domain.

- (Experimental) Open to all users with an OpenID Provider

  If your application uses authentication, anyone who has an account with an OpenID Provider may sign in. To find out more about this, please check out the OpenID article.

Warning:
Currently, you cannot switch authentication options for existing App Engine apps to or from Google Apps accounts for a domain. This option for restricting an application's authentication settings can only be set at app creation time.

## Administering your App Engine Application

With Google App Engine, you can administer your application using a Google Account or a Google Apps account. Your app's administration account should use the same authentication as the app's users. For instance, if you set your app's authentication to Google Apps, you should administer that account using a Google Apps email address.

If your App Engine developer account is a Google Account, you can access the Administration Console at https://appengine.google.com. If you are using a Google Apps account which has not transitioned to the new infrastructure, you can access the Administration Console at https://appengine.google.com/a/YOURDOMAIN (substituting YOURDOMAIN with your actual domain name).

## Restrict your application's authentication to members of your domain

The option for restricting an application's authentication settings can only be set at app creation time, so your first step is to create a new application.

By default, Google App Engine applications use Google Accounts for authentication, which means that if your application uses authentication, anyone with a valid Google Account will be able to sign in.

If you'd like to restrict your application to members of your Google Apps domain (i.e. only users with accounts on `example.com`), click on the 'Edit' button at the bottom of the Authentication Options box.

Select the radio button next to 'Restricted to the following Google Apps domain:' and enter your Google Apps domain (e.g. `example.com`) in the text box and click 'Save'. You will be taken to a confirmation screen indicating your application has been successfully registered.

## Changes from the Google Apps account transition

In 2010, Google announced and started the Google Apps transition, which expands the set of Google services available to Google Apps users. Now all Google Accounts, including Apps accounts, use the same authentication mechanisms, so Google Apps users can now sign in to your applications without any additional work on your part. This section describes how this transition appears to App Engine developers.

Applications set to Google Apps Accounts continue to behave as before.

### Signed-in users

The Google Accounts setting previously did not allow users with Google Apps accounts to sign in. Now, they can. (Note that this does not include older Google Apps accounts that have not yet transitioned to the new Google Apps infrastructure.) One implication of this is that an application using the login:admin (in Python) or auth-constraint role-name admin (in Java) restriction, including builtins such as remote_api and datastore_admin, can use a Google Apps account to access those pages on applications set to allow access to all Google Accounts.

An application using the Google Accounts setting can deterimine if the currently signed-in user is using a personal Google Account or an account which is managed by a Google Apps domain. This is done by checking the runtime environment. In Python, this can be read using `os.getenv['USER_ORGANIZATION']`. In Java it can be read using `ApiProxy.getCurrentEnvironment().getAttributes().get("com.google.appengine.api.users.UserService.user_organization")`. This value will be blank for a Personal Google Account, or if no user is signed in.

### Conflicting Accounts

Some users have created what is known as a conflicting account. A conflicting account is an account hosted on the Google Account infrastructure, created with the same email address as a Google Apps account. To resolve the conflict in account names, the Personal Google Account is renamed with a different account name.

From an App Engine application's perspective, a user with a given user_id may now have a different email address than before. Conversely, a user signing in with a particular email address may represent a different user, as identified by their user_id. As users could previously only use their personal Google Account to sign in to your application, they may be surprised by this behavior: a user with a conflicting account who continues to use the same email address is actually signing in with a different Google Account.

Note that this same pattern appears when a user renames their Google Account, for all types of Google Accounts: the email address may change for a given user_id.

If you have used a User object in the datastore, it has associated the old email address with the user's user_id. This means that equality comparisons will no longer be valid. It is a best practice to use the users user_id as the key to a datastore entity.

## Configuring Google Apps to Authenticate on Appspot

In order to restrict your application to members of a particular Google Apps domain, you will need to add the app id to your Google Apps account through the Google Apps control panel (i.e. open `http://www.google.com/a/YOUR DOMAIN`).

After signing in to your Google Apps Control Panel, click the 'Add more services' link on the Dashboard:

On the 'Google Services' page, enter your Google App Engine app id under 'Other Services'.

Once you agree to the Terms and Conditions, your application will be configured to serve Google Apps authentication off of the `appspot.com` domain. To serve the app off of a Google Apps URL, please see our article.

Note: App ids added to Google Apps prior to March 13, 2009 will need to be re-added in order to support serving Google Apps authentication off of `appspot.com`.