OAuth Listening Tour

From IIW

Issue/Topic: OAUTH Listening Tour

Session: Tuesday 1E

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

Convener: Mike Jones

Notes-taker(s): Sunir Shah

Tags:

Discussion notes:

OAuth

Who's here and what do we want to get from this session?

  • Brian Campbell, OAuth2 for Ping; SAML OAuth profile
  • Sunir, FreshBooks. OAuth for App Sotre
  • Patrick Harding, Ping.
  • Harish. Implemented OAuth 1.0. Want to move to 2.0
  • Hiroki, NTT. how to deploy openid and oauth in enterprises
  • Steve Weiss, AppDirect. OAuth to integrate with vendors. keep up to date
  • Dirk, Google. implemented OpenID+Oauth hybrid
  • Jacob, ATT. Where is OAuth2 going.
  • John Trammel, Adobe. OAuth2 and OpenID connect projects
  • Vijay, VMWare. How can we use OAuth to specifically for app authentication, authorization
  • Mike Donaldson, Ping. Realization of OAuth2
  • Marius, Google. OAuth2 implemention while supporting OAuth 1.0
  • Macduff Hughes, google
  • Nat Sakimuri, Nomura Research Institute, mobile web app flow
  • Tom Addison, Ping. Use cases for OAuth
  • Mike Jones, Microsoft. Spec work on OSes and identity. Recently chosen to edit the bearer tokens portion of OAuth2 specifications.
  • Dev, Grad student at Berkeley. Security research wrt OAuth
  • Frank, eBay. Teams implementing OAuth2.0
  •  ??, Google China, federated login project


Eran is going to be editor of basic OAuth flow. Mike editor of how to use bearer token to obtain access. Section 6.


What is the bearer token portion of OAuth2?

Section 6.


Problems implementing OAuth2 while supporting OAuth2

  • the way headers are described is not clean when trying to also support OAuth1.
    • the way headers are defined are similar to Basic scheme, but using OAuth. and then you just have the token. No using post way to disambiguating from OAuth1 because all characters in Oauth2 are allowed in 1 (or vice versa). We know that tokens can't have commas so that's how we distinguish
    • eran wanted different endpoints for different protocols, but in reality that is not feasible
    • It's ugly to try parsing with one Strategy and if it fails, try another Strategy
    • My preference is the scheme name for OAuth2 should be "OAuth2". It's fine if it were "OAuth", then it should be a name=value pair.
    • signatures are coming to OAuth2, so at some point you have to deal with signed OAuth tokens
    • up until version 5 or 6 scheme name used to be "token"
    • isn't it normal to use key-value pairs;version=
    • Basic contradicts all other RFCs. Basic is not standard. Should have name-value pairs
    • Basic is a huge precedent, but typically a list of name-value pairs.
  • BNF is ambiguous
  • Post very query parameters use cases unclear


NRI is using OAuth2 as basis for OpenID Artifact binding

  • using post instead of header because in our case the token can get pretty big

Google: If you have to parse the whole post it's a huge hit. We'd rather have it in the query parameter


How many profiles do I need to support?

  • not required to support everything. depends on use cases
  • no conformance
  • OAuth2 you have to support header method

The split of when to use bearer tokens and when not to.. is there guidance?

  • What will help the implementor to decide what is appropriate?
  • the generic answer is to write guidance documents about when it is appropriate to use a bearer token, what are the risks are you taking, when is

that inadequate in a security context

  • finishing the security consideration section is what's missing
    • HELP REQUESTEd: input on what language should be in security section

Each section should have its own security section

I don't think you can assume security consideration for bearer vs user tokens are the same.

The OAuth framework would describe the hooks for token scheme. Signature would use hooks to add more fields for signing

Goal of turning Internet Draft into standards tract

Eran believes when we have draft 11 including the split, it will go out for comment. It's possible that Draft 12 will become the standard

We will attempt to get to final text and have standards directors review it.

Eran believes the standards directors to change a should to a must, e.g. MUST use TLS.

TLS assumes a particular kind of deployment. We don't have the same requirements as Google and Facebook. The SHOULD makes more sense for our case.

I work in gov't: Long history of stovepipes (vertically integrated application stack). You need to know everything from top to bottom. So OAuth used in closed environment, so a lot of security considerations don't apply to use in the same ways. It's one of my goals that the OAuth spec doesn't drift far away from our use cases that we have to be really out of compliance.

We should stop changing things. We have six implementations of Draft 10.

  • but signatures, bearer tokens not included?
  • draft 10 is OAuth framework. fix that so it will be faster to do signatures

spec.

  • breaking existing deployments is part of the risk of implementing a draft
  • making changes should be focused on bugs

Client Implementors guide

  • message sequence charts
  • detailed example flows of headers and exchanges
  • a little more of the Why does this profile work, and why does it exist like this?
  • should live on OAuth.net as an implementor's guide

Where is 2-legged OAuth in the spec?

  • I don't see an analog in OAuth2
  • Native application is closest
  • Some profiles supposed to address that
  • signed OAuth profile group should address that
  • signed http requests
  • at IIW east a bunch of people went through those sections

We're using the client credentials profile replaces what would have

traditionally been 2-legged OAuth.

  • We send short term bearer token across the wire to the protected resource

As OAuth2 is more modular, many ways of doing the same thing.

  • client credentials flow /assertion flow to get access token
  • bearer token
  • token with signature

Can there be a recommended implementors guide for best practice to support 2-legged OAuth?

Retrieved from "https://iiw.idcommons.net/index.php?title=OAuth_Listening_Tour&oldid=3586"