[Q] Using go-pkgz/auth for authenticating mobile apps about auth HOT 4 CLOSED

I believe all of this can be done without any changes on the library level by doing auth in the native web browser and after this calling your own, custom handler to get the token. This is very similar to what we do in the provided example. All you need to change here is to respond with the token retrieved from the request. From this point, assuming you can capture the token from browser's response body and pass it back to your mobile code, you will attach it to each https request as a header (default is X-JWT).

In the plan you described above the step (2) is unclear to me, namely the part "ensure the redirect_uri is sent to my app on iOS and Android". I have no clue how this can be done on multiple levels. First - how exactly are you going to have such a dynamic redirect url and the second - how this redirect will even reach your app. I.e. such app needs to act as a server and have ports open and properly forwarded on lan, which is an unrealistic expectation. Another thing I don't really get is the "authorization code" you mentioned. Why you need an authorization code if you can use an existing one, i.e. JWT?

Pls note - I have zero practical experience with mobile development, so maybe all I said is complete nonsense ;)

from auth.

Hi @umputun thank you for a very quick reply. I'm not an expert on mobile dev either, however from what I tested, my choices are: use a native browser but then I can't touch the cookies in request nor in response OR I can use a webview inside my app (=tiny browser) but that won't have any cookies set up - so my facebook user will be "logged out" even though they use facebook on the device. Neither of the two options look appealing from a user perspective.

Hence my attempt to pass information to the app from the native browser via a redirect URL. On mobile devices one can actually register "deep links" so on certain URLs, the system (iOS, Android) actually wakes up your app and passes the url to it instead of visiting a website.

If I could access the JWT and pass it to my app as part of that redirect_uri in a parameter, the problem would be solved but I don't see how to do that but I could be missing something. Somehow I had an aversion to passing the JWT through a GET request in the parameters, hence the authorization code (short lived, use only once).

from auth.

I can use a webview inside my app (=tiny browser) but that won't have any cookies set up

Well, I think as you do auth flow it will act as a real browser and will get JWT cookies. I believe, it has nothing to do with your primary mobile browser because this webview widget runs in its own sandbox, or whatever it called on the mobile platform.

Quick googling gave me this article https://www.freecodecamp.org/news/how-to-build-cross-origin-communication-bridges-in-ios-and-andriod-7baef82b3f02/, so looks like it is possible to get webview content from the app. And after you have it you don't need any cookies and all you want is to set a header in each http request. You could also store jwt in your app store and present it the next time user starts the app. If the token expired go-pkgz/auth will try to refresh it and if it expired for real - you could start the login procedure again.

On mobile devices one can actually register "deep links" so on certain URLs, the system (iOS, Android) actually wakes up your app and passes the url to it instead of visiting a website.

If this the case I don't really see a difference between passing JWT in vs some auth code. If for whatever reason, you leak the code it will lead to the same issue as leaked token

from auth.

I fully agree with what you wrote. The problem with webview I mentioned earlier was perhaps badly presented. I was actually able to get the webview working and was able to initiate the login flow to facebook and it was clear how to extract cookies. The inconvenience to the user is on the provider credentials side.

In my case: I am logged into facebook app on my phone and my native browser is authenticated as well (I can verify this by launching the oauth2 request in the default system browser). Yet inside my webview I was presented with a login prompt. This is because the FB cookies are not present in the webview I just created - I have to log in again. This is what I was tryng to avoid by iniitiating the oauth2 flow in the default system browser and somehow extracting data back.

The tradeoffs here are clear and there's likely no easy way to move data from system browser into the app as is, so webview it would have to be. Thank you for your consultation!

from auth.