OAuth the parts intro/review
Session Topic: OAuth the parts intro/review
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.
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?