Consider mobile app <-> mobile app authentication flows

[Joseph Heenan]

We had another discussion about the EU RTS and related areas on today's call.

One point I mentioned is that at least one of the UK challenger banks is doing a mobile app -> mobile app flow which is something like:

1. open accounting app on mobile
2. user requests to make a link to their bank account
3. user is automatically switched into their mobile banking app
4. bank app asks user to allow accounting app access
5. bank app authenticates user with faceid/touchid
6. user is automatically switched back to their accounting app

(I forget which bank this was but it may have been starling.)

From an RTS point of view it seems like a low friction flow so perhaps something we could incorporate into one of the standards; I created this ticket at Nat's request.

[Tom Jones]

This doesn't address the question raised about where then authentication occurs: on the app or in the cloud. I cannot imagine FAPI endorsing the first,

[Nat Sakimura]

So, the mobile banking app may actually be doing something like AppAuth to refresh the authentication status as well as updating the access permission. If the accounting app actually needs to draw data in the background, the server component of the app is likely to draw the data from the bank's cloud API. So, in such a case, the bank's server side needs to be aware of the fact and the bank app necessarily contacts the back end anyways.

[Dave Tonge]

As discussed on the call, for the OpenBanking use case the above flow is not for public clients but for confidential clients.

Both FAPI parts 1 and 2 support such a use case. Part 1 requires PKCE (or will do shortly) Part 2 requires hybrid flow

Both mechanisms (when correctly implemented) protect against code interception attacks which are more likely when using a native app as the user agent rather than a browser.

[Joseph Heenan]

I think (at least on iOS) using the deep linking method to associate the client app to the redirect url and the auth app to the authorisation endpoint also prevents code theft. Android I'm less clear on.

It'll be interesting to see what OB's report says.

I'm not sure if there's anything that we can come up with that would not be more appropriate to add to https://tools.ietf.org/html/bcp212 instead.

[Dave Tonge]

I suggest that we reference BCP212 and in particular require that: 7.2 Claimed "https" Scheme URI Redirection is used rather than 7.1. Private-Use URI Scheme Redirection

For more info this is supported on iOS as follows: https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html?utm_source=revxblog

And on Android as follows: https://developer.android.com/training/app-links/verify-site-associations

@josephheenan @Nat do you think we need to be clearer in our requirements for the redirect_uri

• FAPI just says it must be pre-registered
• RFC6749 says it should be https (but doesn't say must)
• OIDC says for code and hybrid flows: the Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

I'm in favour of saying it MUST/shall be https - this will still support iOS/android as described above, however it would limit support for native applications on macOS / windows.

We kind of imply that it should be https when we say: all interactions shall be encrypted with TLS (HTTPS). but I think it would be helpful to make it explicit given the optionality available in other specs.

[Joseph Heenan]

I think an explicit clause that requires the AS to reject non-https redirect uris would clearly make everything clearer.

I think there's some missing link - everything you say about BCP212 & 7.2 makes sense, but my understanding is when a third party app opens safariviewcontroller to show the user the authorisation endpoint, safariviewcontroller will NOT respect universal links, so the user will be shown the bank's website rather than the bank app.

I don't recall BCP212 mentions this, and (assuming I'm right that it's a problem) I'm not sure how people are solving it in the real world.

[Dave Tonge]

We have a real world implementation using safari view controller / chrome custom tabs that supports universal links / site associations. Maybe there is an option to tell safari view controller not to do that, I'll have a look.

[Nat Sakimura]

Any updates? Shall we include it in the 2nd Implementer's Draft?

[Nat Sakimura]

Dave will try to add some wording to it but this is not a blocking issue.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/69/add-clause-relating-to-native-apps/diff

[Nat Sakimura]

Can we close this? cset <<cd2371f>> seems to have fixed this.

[Dave Tonge]

Yes it can be closed

[Nat Sakimura]

Merged in josephheenan/fapi/localhost-for-developers (pull request #75) to fix #145.

Encourage authorisation servers to allow localhost urls

Approved-by: Nat Sakimura [e-mail] Approved-by: Dave Tonge [e-mail]

→ <<cset 81348e639fda>>