Updated by Rufus, June 2011. Updated by Matthew Blain, October 2011.
With Google App Engine, you can use Google Apps to:
- restrict your application to members of your domain
- 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
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.
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 determine 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.
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. Please follow the Add services to your account instructions on the Google Apps Documentation page.
When you are selecting services look for the input to enter your Google App Engine App ID.
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