Hey guys,
is there a way for mobile apps to log in...
# support-questions-legacye
execreate
10/14/2022, 5:21 AMHey guys,
is there a way for mobile apps to log in users with some on-device authentication mechanism (FaceID / Fingerprint) with Supertokens?
execreate
10/14/2022, 5:27 AMI think some way to create a long-lived session bypassing the default access/refresh tokens lifetime setting on the core would help to deal with this problem.
Here is how I can imagine the flow:
1. User has no authorization, is redirected to the in-app browser authentication page
2. Logs in as usual web app users
3. The mobile app gets access and refresh tokens from cookies (is that even possible for a mobile app to retrieve http-only cookies from the web view?)
4. The mobile app then requests the backend to generate a long-lived token
5. The backend sends corresponding request to the Supertokens core
6. Supertokens core generates a long lived token that can be further verified to belong to a specific user
7. The backend sends the token to mobile app
8. The mobile app securely saves the token in Apple Keychain or something similar for reuse
9. Next time the user opens the application, FaceID unlocks the Keychain so the mobile app can retrieve the previously saved token and exchange it for an access and refresh tokens
r
rp_st
10/14/2022, 6:11 AM> The mobile app gets access and refresh tokens from cookies (is that even possible for a mobile app to retrieve http-only cookies from the web view?)
I don't think so.
But what you could do is as follows:
- Enable JWT in session recipe on the backend
- When the user logs into the web view, redirect the user to a deep link with the JWT from the session. This JWT will then be available in your mobile app. Or maybe there is some other way to transfer info from webview to app? Not sure.
- Send the JWT to the backend, backend verifies it, and creates a new long lived JWT which your app will store in keychain guarded by faceID. Along with that, the backend will create a new regular supertokens session as well.
- When the user opens the app again, face id unlocks the keychain to get the long lived JWT which can again be used to create a new session.
e
execreate
10/14/2022, 6:12 AMThank you @rp_st 🙂
r
rp_st
10/14/2022, 6:19 AMactually, on second thought, using the JWT like this only makes sense if you send that to the APIs for session verification and not the access / refresh tokens
rp_st
10/14/2022, 6:20 AMcause the tokens that actually grant you access is not the thing that's stored in keychain
rp_st
10/14/2022, 6:20 AMso for the mobile session, just use the long lived JWT and that's all. Don't bother with creating a regular supertokens session for it.
e
execreate
10/14/2022, 6:28 AMYeah, that makes sense
Btw, is it possible to keep http-only access/refresh for our web users?
r
rp_st
10/14/2022, 6:28 AMwhat do you mean by "keep"
rp_st
10/14/2022, 6:28 AM?
e
execreate
10/14/2022, 6:32 AMI mean, JWT's are less secure than the default Supertokens session management, right? So I'd rather keep the default session management and enable JWTs only for mobile users
execreate
10/14/2022, 6:32 AMWell, I guess I can connect 2 backends to the supertokens core and enable JWT only on one of them 🤔
r
rp_st
10/14/2022, 6:33 AMyea. That is possible.
If you want ot have the same backend, you could make your own session verification middleware which tries both, verifySession from supertokens and JWT based session verification and returns the userID from whichever matches.
e
execreate
10/14/2022, 6:34 AMcool! thanks @rp_st 🙂
7 Views