Mobile apps blocked by current handling of OAuth callback URLs

[t0rst]

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

[constantine2nd]

@t0rst

4. consumer credentials become invalidated somehow (to be further investigated): possibly when updating the registered callback You are right. Updating of redirect url also set isActive=false

[constantine2nd]

x-com-tesobe-obp-ios-starter://callback cause next exception when we use java.net.URL class for URL validation:

• java.net.MalformedURLException: unknown protocol: x-com-tesobe-obp-ios-starter at java.net.URL @t0rst Question is does the callback URL is actually URI? In that case we can use java.net.URI instead of java.net.URL.

[simonredfern]

suggest we use java.net.URI then!

[t0rst]

@constantine2nd In general on iOS/macOS, the scheme is used to locate a resource: a url gets sent to the system's registered handler for the url scheme, hence if the scheme is https, the default web browser is expected to provide the resource (and the iOS/macOS app doesn't get a look in). When the scheme identifies the app (x-app-id) then OS asks the app to find the resource.

(I'm not a seasoned server-side person, so I keep refering back to this stuff:) RFC 3986, §1.1.3

A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location").

...in that sense its a proper url: tells you what resource ("callback"), and how to get there ("x-app-id") (even if "callback" is just a mechanism to close the communication loop, and its contents are not relevant - is that what you meant by is it a URI?)

[t0rst]

Test results:

• log in now possible after new callback registration via updateConsumerRedirectUrl ⇒ custom iOS schemes accepted in update call, credentials no longer deactivated, and scheme not rejected during log on process. (→ HelloOBP-iOS is working again)

Still to do:

• URL's with iOS/macOS schemes still being rejected by consumer-registration (Action request #1 above) (→ blocking simple pay demo app)
• Action's #3 & #4 above are worth doing - I see that people are getting snagged by this problem and posting on slack #general

[constantine2nd]

@t0rst Could you please provide us exact message for URL's with iOS/macOS schemes still being rejected by consumer-registration if any.

[t0rst]

By the way, any chance you could shorten the unregistered error message as well? == item 4 of Action Requests: in the original issue description above.