Mobile App AuthN/AuthZ against a Pomerium protected resource

We are trying to grant access to an existing resource protected by Pomerium Enterprise so that a Mobile application (iOS, Android) can access the resource. What is the best approach to allow users who already have web-based access to the resource to also be able to use the mobile application with the resource?

It looks as though this is a candidate for utilizing API based authentication https://www.pomerium.com/docs/capabilities/programmatic-access. Would this be the best approach?

Yes, currently you should be able to do that using programmatic login workflow.

  1. user starts an application and requires access to the resources protected by Pomerium
  2. an application starts a local web server on some random port, i.e. http://localhost:8888 - there are packages for iOS and Android ecosystem, look for the embedded web server. It needs implement a callback handler that would obtain the authorization JWT.
  3. an application creates a web view control with URL to the destination route - i.e. https://my-route.my-domain.com/.pomerium/api/v1/login?pomerium_redirect_uri=http://localhost:8888.
  4. When the programmatic login completes, the embedded web server handler would obtain the JWT, and may close the browser window control at that point.
  5. Now that JWT may be used by the mobile application while invoking a calls to the protected resource (https://my-route.my-domain.com), until the JWT expires (which should match the Pomerium session max validity period), and reflected in the JWT exp field. When JWT is no longer valid, an application should pause the normal work and repeat the authentication flow described above.

Does this work with custom protocol handlers? i.e. if we want the callback uri to be my+custom+app://callback, can we register that in the whitelist, or are only http and https supported?

custom URL schemes are generally deprecated and replaced with universal links across iOS and Android. see Apple Developer Documentation

I personally wouldn’t recommend going this way (including binding universal link with your app), as it’ll create a recurrent dependency with the above described scenario.

Understood. We will go the Universal/App Links route since that is now best practice.