Handling Unregistered Clients

From IIW
Revision as of 15:17, 3 February 2011 by WikiSysop (talk | contribs) (Undo revision 3054 by Igiwydijok (Talk))

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Issue/Topic: Handling Unregistered Clients in OAUTH2 & Open ID Connect

Session: Tuesday 4I

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

Convener: David, Kevin Marks

Notes-taker(s): Kevin Marks


Discussion notes:

Currently OAuth 2 in practice requires pre-registered developer information, specifically the callback URL, and obtaining access tokens that are built inot the site.

This has 2 problems:

  1. requires up-front work by developers to try things out
  2. is problematic for non-web clients (mobile, desktop) as they need to bounce stuff via a website to work.

The advantage for the host site is that they can track and throttle developers calling APIs and have TOS agreement and verified contact address for them.

Other options:


Advantage is that this is very easy for developer to try things out; drawback is that host can't identify by app easily, and potentially leaking user info:

  • give public subset of data
  • warn strongly in auth dialog
  • throttle strongly

Dynamic allocation

Advantage is that the flow is closer to registered flow, and because host can distinguish apps, can apply er-app throttling/monitoring. Above use suggestions may still be useful

Callback endpoint Discovery

By applying WebFinger or other ./.well-known/ based discovery to the callback URL, the host can validate the callback does belong to the site and is not a redirector, and get logo, description and other metadata to show the user. Potentially this could also be used for key discovery and verification between sites, for the University/ Salesforce / Google Apps use cases, though that is currently hard on purpose because of the broad access permissions there.

IIW11 TUE 4I 1.jpg