Authentication to the Calendar data API can be done using several methods:
- AuthSub authentication is intended for multi-user web applications. With this method, users visiting your web applications are redirected to a Google server to authenticate to their Google account. After approving your application to access their calendar, the user is then redirected back to your application with a
tokenvalue. Thistokenis then exchanged for an AuthSub session token that is valid indefinitely for access to the user's calendar(s) or until the user revokes access. - ClientLogin is intended for installed applications. Using this method, your application supplies the user's credentials directly to Google in exchange for a token value. This token value is then used to access the user's calendar(s). This method is not for use by multi-user web applications.
- Magic cookie/private address authentication is the easiest method to provide read-only access to a calendar. In this authentication scheme, a special random string of characters is added in the private visibility feed URL. Disclosing this URL or the string of random characters is essentially disclosing a password for read-only access to a calendar. This string can be reset by a calendar's owner at any time.
- HTTP cookie authentication is used when a feed is retrieved through the web browser of a user who is currently logged into the Google Calendar UI. These HTTP cookies can be used for read-only access to the Atom or RSS formatted feeds only. Alt types of
jsonorjson-in-scriptwill not work with this method of authentication. Note: these cookies are different than the 'S'-cookie used for session handling and are also different from the "magic cookie" feeds described above. As read-only feeds, these do not include references to the edit URLs (<link rel="edit" href=.../>) needed for updating or deleting entries. This feed method of authentication is most often used by developers for learning and debugging purposes.