OAuth the parts intro/review

From IIW
Jump to: navigation, search

Session Topic: OAuth the parts intro/review

Tuesday 5J

Conveners: Dick Hardt/Dan Blum

Notes-taker(s): Dam Blum

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Note: this session was combined with the session OAuth 2.0 Assurance by Dan Blum

Summary: Attendees of this session were primarily interested in sharing observations on OAuth best practices. After some discussion, a debate arose about best practices for securing the OAuth interaction with mobile clients. This debate wasn't resolved.

General Notes:

OAuth is a framework, not a protocol

As client, you don't know where the access token came from

Many implementations still use OAuth 1, there was some discussion of this but no strong reason or justification to continue focusing on OAuth 1 was expressed at this meeting

How do you build an API that lets people run apps that register people on the device what are the best practices? Use access tokens over SSL.

Major social networks (e.g. salesforce) are giving developers samples that are "like" what they are trying to do, often this is driven by historical reasons

Secure OAuth use with mobile devices discussion / debate

Dick Hardt advises

  • Don't use implicit flow; register device
  • Separate mobile client app seeking access to OAuth data into two parts:
    • 1) the user agent on the device and
    • 2) server component
  • Store the app tokens in the client server, store only per-device tokens on the endpoint; this effectively means that every endpoint is registered

A debate arose: what is the value of dynamic registration when you can't authenticate the device to begin with?