Skip to content

Instantly share code, notes, and snippets.

@phwd

phwd/gist:e74c3304b566d1717b72eaaf2aed3336

Forked from jaredhirsch/gist:4dcd73653dd5f9a4dacc
Created April 6, 2016 13:06
Show Gist options
  • Save phwd/e74c3304b566d1717b72eaaf2aed3336 to your computer and use it in GitHub Desktop.
Save phwd/e74c3304b566d1717b72eaaf2aed3336 to your computer and use it in GitHub Desktop.
Download ZIP
oauth 2, some notes
Raw
gistfile1.md

I did a bit of initial OAuth research this week for FxA (Firefox Accounts). It was interrupted by more pressing stuff (bugs bugs bugs), but thought I'd post my incomplete work-in-progress notes for whenever I get back to this.

Notes come from Getting Started with OAuth 2.0, which I accessed via Safari.

my next steps:

  • look carefully at a number of JS SDKs
  • think in terms of a generic OAuth abstraction for FxOS
  • but begin by building the simplest possible solution for FxA on FxOS
    • we really need implicit grant,
    • and a proxy server that could handle redirects on behalf of serverless apps,
    • and a token validation server.
  • If we had all that, we could build a really simple JS SDK that works on the real web and FxOS, and avoids getting mired in the rather slow Gecko/Gaia timeline

Client Profiles

  1. Server-side web app
  • can hold secrets without user seeing them
  • can talk with resource server without user intervention
  • uses secrets to generate tokens / regenerate tokens (refresh token)
  1. Client-side web app
  • can't put secrets here -- user secrets yes, app secrets, no
  • OAuth's solution: short-lived bearer tokens
  1. Native app (desktop or mobile)
  • like browser app, you can't put app secrets here
  • even worse, might not have full browser capabilities (just embedded webviews)

Sending tokens to server

  • HTTP Auth header
    • only required method in the spec
    • preferred because
      • rarely logged by proxy servers/web servers
      • rarely cached, including not stored in browser cache
  • Other methods:
  • Query parameter (for GET requests)
  • Form-encoded body parameter (for POST requests)

Auth flows/grant types

  1. Auth code
  • used for server-side web apps
  • request sends client secrets (client_id, client_secret)
  • response includes bearer token and refresh token
  1. Implicit grant
  • simplest flow, designed for browser-based requests
  • user enters creds, redirect contains short-lived token
  1. Resource owner password-based access grant
  • user gives creds to app
  • app gets long-lived access token & discards user creds
  • user can revoke app access without needing to change password
  • token is scoped, another advantage vs storing password
  1. Client creds
  • app, not user, has creds for resource it (not user) owns/controls
  • irrelevant to our use case

Some existing JS and mobile APIs?

Facebook's "roll your own" docs

  1. Logging in
  • open a dialog at fb.com/dialog/oauth?client_id={app_id}&redirect_uri={uri}
  • if you're in a desktop app, using a webview, then redirect_uri must be fb.com/connect/login_success.html
    • not sure why?
  • interesting note that win8 apps use "Package Security Identifier" & ms-app scheme (though it's unforgivably wordy):
var requestUri = new Windows.Foundation.Uri(
  'fb.com/dialog/oauth?...&redirect_uri=ms-app://{package-security-id}
);
Windows.Security.Authentication.Web.webAuthenticationBroker
  .authenticateAsync(options, requestUri)
  .done(function onLogin(result) { /* do something with login */})

After login, you're granted a token or a code.

  • Given a token, use fb.com/debug_token to verify app ID and user ID.
    • This prevents malicious fake redirects
  • Given a code and a client_secret, you can obtain a token
    • As mentioned above, client_secret can't be stored in binaries/websites, only on secure servers

Refs/link dump

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment