Mobile apps blocked by current handling of OAuth callback URLs

TL;DR:

1. Unregistered OAuth callback URLs rejected after auth token request validated → many previous mobile API consumers won't work
2. API consumer registration rejects valid callback URLs needed by iOS/macOS apps (custom scheme, not https)
3. Re-registration workflow presents obstacles.

Callback URL registration

1. Unregistered callback urls now blocked (good security)
2. iOS/macOS app devs...
   a. have extra requirements on callback url,
   b. likely don't know at time of first api consumer registration
3. updating registered callback later requires that
   a. you remembered your consumer ID, which is shown in registration confirmation screen, but not in the confirmation email (security)
   b. have the CanUpdateConsumerRedirectUrl entitlement, which is not granted by default; have to ask for it
4. consumer credentials become invalidated somehow (to be further investigated): possibly when updating the registered callback:
   i. initially using working credentials but with unregistered callback:
   a. proceeds through OAuth token exchange sequence successfully, and then…
   b. gets to the callback check and gets rejected with a UI message, which is cropped (see below)
   ii. after using #2_1_0-updateConsumerRedirectUrl to register the actual callback that will be used (was accepted by API call) →
   a. OAuth token exchange sequence now fails with "OBP-20009: Invalid consumer credentials" - this is the stage before the callback is checked, hence suggests that the expected credentials have changed or that existing credentials have been marked invalid.

iOS/macOS requirements for callbacks

iOS/macOS apps use custom callback schemas that i) uniquely identify the app on the iThing/Mac, and ii) is declared in the app's meta data, so that the system learns of it and then knows to dispatch matching formed URLs to the app. This essentially means deriving from the app ID - typically the app resource definition for its meta info includes a scheme formed by x-${PRODUCT_BUNDLE_IDENTIFIER:lower}, hence you will see callbacks like x-com.tesobe.helloobp.ios://callback; OBPKit handles this for developers.

The app id will most likely change at some later point in the development lifecycle, hence there's a need to be able to change the registered callback easily.

This mechanism was working fine until checking for callback registration was tightened up.

Action Requests:

1. Don't reject valid custom schemes in the callback URL (RFC 3986, §3.1: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) )
2. Find out what's going wrong after using #2_1_0-updateConsumerRedirectUrl
3. Add prominent note (text in red?) to the consumer registration result screen saying "Save a PDF copy of this for your records. (You will need the consumer ID if you need to register a different callback later.)"
4. Shorten rejection message to
   "Sorry, the App requested a redirect to an unregistered URL. (Developer note: re-register your URL with PUT /management/consumers/CONSUMER_ID/consumer/redirect_url)"
   (the visible part of the current message is "Sorry, the App requested a redirect to a URL that is not registered. Note to application developers: You can set the redirect URL you will use at consumer registration - or update it with PUT/management/consumers....")
5. Sort out need for entitlement and invalidation of credentials after re-registration
6. (@t0rst:) update iOS/macOS readme notes to explain what to do