Save to Pocket

The easiest, fastest way to capture articles, videos, and more.
Pocket’s Chrome extension is the easiest, fastest way to capture articles, videos, and anything else you find on the web. With one click, the content you’ve collected appears across all your devices in a clean, distraction-free space—there to read when you’re ready, whether at home, at work, or on the go. Pocket becomes a personal, quiet corner of the internet where you can spend quality time with the stories that matters to you.

SAVE CONTENT 3 DIFFERENT WAYS
- Click the Pocket button in the toolbar
- Or right-click a link and select “Save to Pocket”
- Or use the keyboard shortcuts: Ctrl+Shift+P (Windows), Command+Shift+P (Mac)

DISCOVER RELATED CONTENT
- See a list of relevant stories for most content you save
- Add tags to order, sort, and find stories in your Pocket

A HOME FOR CONTENT YOU CARE ABOUT
- Save anything that interests you—articles, images, videos, links—and absorb them when you're ready
- Capture news from Buzzfeed, articles from The New York Times, stories from Flipboard, long reads from Washington Post, and recipes from Pinterest. You can save memes from Reddit, links from Twitter, and videos from YouTube
- Read directly in Pocket, a calm, focused environment

Get Pocket Premium to enjoy custom fonts, a permanent library, unlimited highlighting, and more. Even try listening to articles in Pocket when you're on the go.

Pocket

Over 10 million people use Pocket to easily save articles, videos and more for later.
Webby Award for Best Productivity App 2014

Over 15 million people use Pocket to easily save articles, videos and more for later. With Pocket, all of your content goes to one place, so you can view it anytime, on any device. You don’t even need an Internet connection.
 
Don’t lose track of the interesting things you find by emailing yourself links or letting tabs pile up in your browser. Just save them to Pocket.
 
WHAT CAN I SAVE?
Save articles, videos, recipes, and webpages you find online or from your favorite apps.
 
VIEW EVERYWHERE, EVEN OFFLINE
If it’s in Pocket, it’s on your phone, tablet or computer, even when you’re offline. Perfect for commutes, travel, and curling up on your couch.
 
BETTER VIEWING EXPERIENCE
See your saved items in a simple, easy-to-view layout that improves the viewing experience of any page.
 
WORKS OFFLINE
Access what you’ve saved offline. Set up Pocket to only download when connected to Wi-Fi to reduce data usage.
 
USE WITH YOUR FAVORITE APPS AND SITES
Whether you’re browsing online or on-the-go with your favorite apps, Pocket lets you save great content wherever you find it. After you’re done reading, send the articles and videos you love to another friend’s Pocket, or share to Facebook, Twitter, Evernote, or Email.

POCKET PREMIUM
Upgrade anytime to Premium for a more powerful Pocket experience. Pocket Premium unlocks a permanent library for the articles and webpages you save; gives you full-text, topic, tag, and author search to help you find exactly what you’re looking for; and delivers suggested tags that take the work out of organizing your list.

Supporting Federated Login with Google Accounts for Chrome Web Store Apps

When a user installs and launches your app from the Chrome Web Store, odds are they’ll be signed in to their Google Account. If your app requires authentication, then you should significantly streamline the process for your users by supporting Federated Login to allow users to sign in to your app using their Google Accounts. In this article, we’ll cover some the basics of Federated Login using Google Accounts, things to consider when designing your authentication flow, some examples of apps that allow users to sign in using their Google Accounts, and resources to help you learn more and get started.

Federated Login, based on the OpenID standard, frees users from having to set up separate account credentials for different web apps, and frees developers from the task of implementing login authentication measures. OpenID achieves this goal by providing a framework in which users can establish an account with an OpenID provider, such as Google, and use that account to sign in to any web app that accepts OpenIDs.

Google supports the OpenID 2.0 protocol, providing authentication support as an OpenID provider. A third-party site can request Google to authenticate users who are signing in with an existing Google Account. Google will return an identifier to the third-party site that the site can use to recognize the user. This identifier is uniquely identifies the user, enabling the third-party site to recognize the user across multiple sessions.

When deciding how to structure the authentication flow for your app, keep the following considerations in mind.

If so, you can provide users a way to link their new accounts with their existing accounts. For more guidance and best practices for handling and linking legacy accounts, see this article. In the Examples section below, you’ll see a walk through of the account creation process for Springpad, which gives the user the choice to link with an existing account or continue as a new user.

You can further streamline the process for users by supporting a different authentication flow when your app is launched via the Google Chrome app launcher as opposed to a bookmark or link. You can use JavaScript to check whether window.chrome.app.isInstalled is defined. If it is, the app is running from the Google Chrome app launcher, and you can assume they’ll be signing in via their Google Account. Here’s an example of the code you’d use:

With OpenID, you can request information such as first name, last name, email address, region, and language. You request this additional information by including attribute exchange parameters in the authentication requests that you send to the Google OpenID endpoint. What if you require additional information such as settings related to your app, or if you require a user to accept your terms of service before creating an account? In those cases, you can prompt the user to provide additional information after they’ve opted to sign in with their Google Account. In the Examples section below, you’ll see a walk through of the account creation process for Manymoon, which demonstrates this process. If the extra information is optional, then you can also consider waiting until after a user has created their account to gather this information, in order to simplify the account creation process.

The way you decide to design your user interface may be different if you only support Federated Login with Google Accounts versus supporting Federated Login with Google Accounts and your existing authentication system. See Usability Research on Federated Login for more options.

You have a choice of how users will be prompted for their Google Account credentials. You can prompt them via a pop-up UI, or you can use a browser redirect flow. Our PHP sample code demonstrates how to use the pop-up UI, while the Java and Python sample code uses the browser redirect flow. To try the different styles of authentication yourself, see these examples.

If a user deletes their Google Account, they can no longer sign in to your app using that account. In this case, you could provide a way of associating accounts in your system with a different OpenID identifier, similar to a password reset flow.

This sample workflow walks through the authentication process for an app that supports Federated Login.

This section has some final tips about terminology, federated identity, and where you can get more information.

For consistency with Google Accounts, we recommend using the following terms to refer to account creation and authentication:

  • sign in
  • sign out
  • create

 

When a user is creating an account in your app, we recommend displaying a splash page to the user before prompting them to sign in to their Google Account. Displaying a splash page provides context to the user about why they’re being asked to sign in to their Google Account. The Springpad app in the Examples section above demonstrates one possible layout for a splash page. See Usability Research on Federated Login for more options.

Make sure you’re using the correct federated identity URL when you request the OpenID endpoint. The URL you should use to get the Google OpenID endpoint is https://www.google.com/accounts/o8/id.

Here are some places where you can find more information about OpenID and Federated Login for Google Accounts.

  • For technical guidance on using Federated Login for Google Accounts, see the documentation for working with OpenID.
  • The Identifying the User section of the Chrome Web Store Developer’s Guide provides more details on when supporting Federated Login with Google Accounts is required and when it’s optional, as well as a listing of OpenID libraries you can use.
  • For sample code that demonstrates how to obtain the OpenID identifier for a user and how to use the Chrome Web Store Licensing API, see these samples for Java, Python, and PHP.
  • Visit the Google Group on Federated Login for discussion on using Google’s OpenID API.