Handling Unregistered Clients
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
Tags:
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:
- requires up-front work by developers to try things out
- 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:
Anonymous
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.
