14

So the standard SSO approach for native mobile apps (both Android and iOS) appears to be OAUth2 + OpenID Connect via the AppAuth library.

That's all well and good -- and actually seems to approach elegance.

But what if the very same app contains embedded web view component(s) which need to access resources using the same SSO (on the same server in the same web apps as the native code where all resources require authentication for access)?

For starters, OAuth2 access tokens (once acquired) are not automatically propagated to , , etc, hyperlink requests within a web app, right? So do the web app pages themselves really have to be reworked with JavaScript to do such propagation? The mobile app can rewrite the requests to address this, but:

  1. At least on Android this only applies to GET requests (right?)
  2. More critically, this assumes the web app does not need to function in a normal browser client

Is OAuth2 not the right approach here? If so, that seems a shame -- as AppAuth seems pretty nice for the native app side of things. It's just blending basic web view browsing into the picture that really makes a mess of things.

Or is there just some de facto standard JavaScript library that one can mix in with Angular or the like (and then require use of Angular or the like)?

Jess Holle
  • 633
  • 5
  • 15

1 Answers1

8

Lead maintainer for AppAuth here. There is not a standard approach, yet, to what you are describing. The OAuth2 for Native Apps BCP at the IETF takes steps in the right direction (and inspired AppAuth) but doesn't cover how to synchronize authentication state between apps and sites - this is left as an exercise to the reader.

If your main concern is a consistent authentication state between an app and it's associated site in the user's browser, the best approach is typically to delegate authentication to the site, via a custom tab on Android or SFSVC / SFAuthenticationSession on iOS. The authentication would be managed by the site, and once complete, the authentication state can be shared back to the app via a custom scheme or app link / universal link.

Where embedded WebView is concerned, the opposite applies - seed the webview's perspective of the site from the app, as the webview's state will not persist while the app's state should.

I wish there was a better, more standardized solution to this and will work towards it, but for now bespoke, per-service solutions are all that is practical.

iainmcgin
  • 2,691
  • 1
  • 18
  • 24
  • Okay, so I more or less get the basic OAuth2 native app solution, how AppAuth fits, etc. And I could see recognizing an initial SSO login 302 in my web view (as it will be viewing a mix of anonymously accessible, BASIC authenticated, and OAuth authenticated sites -- using various providers in the latter case, not just one) -- and using AppAuth at that point rather than allowing the 302? But then when returning from the custom tab login, I just have OAuth tokens. How should I then apply that to my web view navigation? I could hijack all WebView GETs to insert Bearer but what about POST? – Jess Holle Jul 20 '17 at 18:30
  • The SSO state of the art falls well short of basic auth’s simple, robust, and transparent state machine for a browser client: (1) a request is made without a suitable Authorization header, (2) a nice, unambiguous 401 is returned containing sufficient information to challenge the user for proof of identity, and (3) upon obtaining such proof, the result is used to reissue the request with a suitable Authorization header and applied to all subsequent requests to the same context (host and realm in the case of BASIC). For SSO challenge = web flow and proof = token, but why ditch the rest of this? – Jess Holle Jul 20 '17 at 18:41
  • So, as I dig more and more into this, I'm left wondering whether apps that mix web views and native calls should just let any OAuth2 logins proceed as usual in the web views, have JavaScript pass tokens to the native, and not persist the tokens. It seems closer to just letting the web view "be a normal browser" plus native augmentations, which is the whole point in my case. – Jess Holle Aug 07 '17 at 18:11