Yes, that’s an option that would work but may not be the best user experience .
Alternative is to store the login credentials in a secure encrypted store and use the stored credentials to auto login and refresh the token.
Typically third party auth providers have client side SDKs that handle this kind of stuff on behalf of the app but in lieu of that, the app will have to handle it. If the login credentials has changed (outside of the app), the auth would fail to return the token and you can present the user with the login screen again so they can re-login with the new set of credentials.
I have implemented the implicit flow now. However, I am having trouble getting the session cookie from sync gateway. I am doing a POST to the public api https://myserver:4984/mydb/_session like in @borrrden 's example with “Bearer id_token” as the authorization header . It is returning something like this:
{"authentication_handlers":["default","cookie"],"ok":true,"userCtx":{"channels":{},"name":null}}
which does not contain the cookie information.
What am I doing wrong?
All good. I have discovered it is returned in the header, not the body.
Google is pushing people to use external browsers rather than web views for auth. There’s a security problem in that an app running a web view can easily capture credentials. I think Google may even have made it so their auth will no longer work with a web view.
Yes I have read that. Working on getting Custom Tabs going.
Another question: is there a way to set the session cookie TTL from the public rest api?
Is it feasible to set this to say 30 days?