This project provides an implementation of a client-side (implicit grant) OAuth 2.0 authorization flow.

• Retrieval of a user's token using popups using the promise-based Token.getTokenByPopup() function, that presents the user with the authorization endpoint and returns the token asynchronously.

  (Implementation detail: A successfully obtained access token is handed back to the parent window via window.opener.postMessage and the source and origin of the sending window are verified by the parent.)

• Access token verification using Token.verifyAsync, by requesting token information from the authorization server, verifying that the token is valid and that it was generated by the current client (to prevent the confused deputy problem).
• Storage and retrieval of tokens via the Token.get and Token.set calls in the Token service.
• A preconfigured module for use with Google authentication. Check out the example/js/demo.js and example/demo.html for an example.

Check out the demo by going to example/demo.html via rawhithub.com.

1. Run a static file server in the root directory (the one this file is in) on localhost:9000. Python 2.X: python -m SimpleHTTPServer 9000.
2. Navigate to http://localhost:9000/example/demo.html.

1. Create a project in the Google APIs Console. In the "API Access" tab of the console, create an OAuth 2.0 client ID. When prompted, set the following settings:
   • Application Type: Web application.
   • Site or Hostname: The location at which you'll host these files.
2. Edit authorized redirect URIs and JavaScript origins to match where you will be hosting your site. For example, let's say you're planning to host your site at https://example.com/. In that case, you might upload the angular-oauth code to https://example.com/angular-oauth/. You would then set your client ID settings accordingly:
   • Authorized Redirect URIs: https://example.com/angular-oauth/oauth2callback.html
   • Authorized JavaScript Origins: https://example.com
3. Add googleOauth as a dependency to your app.

4. Configure the TokenProvider with the following minimal settings:

   • `clientId`: (Required.) The client ID of your application, as given by your authentication server.
   • `redirectUri`: (Required.) The URI to redirect back to. You normally have to configure your authorization server to ensure that it redirects back to this point.
   • `scopes`: (Optional.) A list of scope tokens to describe the scope of the access request (more concretely, what information will be requested.) The scopes available for a given service are probably documented by the authorization server.

   For example:

   config(function(TokenProvider) {
     TokenProvider.extendConfig({
       clientId: '191261111313.apps.googleusercontent.com',
       redirectUri: 'http://localhost:9000/oauth2callback.html',
       scopes: ["https://www.googleapis.com/auth/userinfo.email"]
     });
   }).

5. After doing this, you can inject the Token service and enjoy its methods:
   • Request a token with Token.getTokenByPopup(), which returns a promise that resolves to an object with an access_token item.
   • Verify that this is a valid token for your application by calling Token.verifyAsync(accessToken), which returns a promise that resolves to the response of Google's TokenInfo service.
   • If you're able to verify the token, persist it in the browser using Token.set(accessToken).
   • Then when you need that token (e.g., to authorize a web service call), call Token.get().

This is a work in progress! Don't use it in production. Here's some of what's yet to be done:

• Security. While some mechanisms have been implemented to prevent token stealing, the project needs a systematic review of weaknesses. Some things to look out for are outlined in the OAuth specification, which also links to other resources.

  I also don't have intimate knowledge of the browser security model. The isolation of localStorage.

• Testing. Still lacking some confidence in this area, but soon enough I'll need to do something about the lack of tests.
• Customization. Users may not always want to use popups. Perhaps taking over the entire browser window is more appropriate in some cases. (The reason for focusing on popup support is that tokens may expire, and ideally reauthentication should be able to occur without interrupting the state of the application.)
• Browser compatibility and fault-tolerance.
  • I've tested all of one browser (Chrome).
  • The library currently depends on localStorage and doesn't take alternative measures if it's not available.
  • Unexpected behaviors are not handled gracefully. For example, if the user opens the callback page, they aren't presented with a friendly message explaining what might have happened. Ideally, the popup would notify the parent when it's closed (if that's even possible when the site in the popup has a different origin.)
• It would be nice to support more authorization servers out of the box.