RFC: Support native apps with bearer token support

[pilcrowonpaper]

I've gotten a few questions regarding on if Lucia can be used with native apps like React Native, Expo, Electron, and Tauri. Lucia is a server side library so it'll work as long as you have a server your app can call. Something like this for OAuth:

1. user clicks "Sign in with Github"
2. redirected to "api.example.com/oauth?provider=github"
3. Github redirects user to "api.example.com/oauth/github" with code
4. "api.example.com/oauth/github" redirects to "app://idkhowthisworks?access_token=<session_id">
5. store "token" (ie. session id) in device

Unlike regular session ids, it should be long lasting (like a year). The client can now make requests by sending the token as a bearer token in the authorization header.

For token renewal, I'm not sure what's the best way to go. You can just disable it all together, or just send a 401 whenever the token is expired and let the client renew it.

API change

I think adding a way to validate access tokens would be enough:

const authRequest = auth.handleRequest();
const { user, session} = await authRequest.validateToken();

Unlike validateUser(), it should not renew idle sessions.

Docs

Maybe add a "Native" framework id, and add guides to Electron, React Native, etc? This part I need the help most :D

[FredBuild]

👍🏻 I am looking forward to this feature! I suggest adding guides to the CLI as well.

[richtommmy]

me too)

[pilcrowonpaper]

I'm guessing there's 2 ways of handling auth.

Use app as the auth client

Use fetch() (or equivalent) to send user's credentials to a web server, which returns a token if valid. Simple.

Use web as the auth client

Validation happens in the browser. Token is sent with deep-linking (myapp://<token>), or the app detects navigation on the browser window and extracts the token stored in the params.

I'm going to guess that listening for navigation is the easier option for desktop (?):

framework	support	notes
electron	✅	seem simple?
tauri	⚠️	available only in Rust

For mobile (Expo and Native), still looking into it

[SergioRibera]

Reviewing, it seems to me that to make a correct integration with tauri it would be necessary to rewrite the library but in rust, this for security issues, this can have 2 benefits, the use in tauri (through a tauri plugin) and its integration in backend systems, either rocket, wrap, actix or even its base use in some service.

I think I can help with the Rust and tauri part.

PS: Tauri has in development mobile implementations so even the integration in tauri could already be mobile.

[pilcrowonpaper]

@SergioRibera Yeah, I'm not making Lucia for Rust (maybe someday though). I'm interested in having guides for each native framework, and that's the biggest bottleneck. In my mind, the client should be relatively simple but I may be under severely under-estimating the work needed. The example should be something like this:

1. App opens browser window
2. Server handles stuff (easy)
3. Listen to navigation => extract token from url
4. Store token in device
5. Send simple GET request with token

[SergioRibera]

Ok, I think I have you, I'll create the project and in a few days I'll tell you here a little about how it's planned to be done

[pilcrowonpaper]

Thanks, let me know if you need any help!

[SeanCassiere]

Looks like Tauri has a plugin already for deep-linking with an open issue on their github.

[lmssiehdev]

any update on using this with expo?

[pilcrowonpaper]

I'll likely add a guide on Expo but it might take a while

[damianmarek]

Definitely waiting for it

[andrictham]

Eagerly waiting for it too! Especially for Expo on iOS and how to deal with “Sign in with Apple”.

[victorbueno]

I'm developing a sveltekit server. I want to use it for an Expo app. It seems that we do not have it yet. I'm going to finish testing tomorrow. If it does not work, I'm going to have develop all the logic and wait for Lucia to keep up.

[trevorpfiz]

does “Sign in with Apple” work by following the Expo guide?

[Blankeos]

Hi @pilcrowonpaper, ik this is probably really old. But just a question...

But would you actually recommend passing the session_id to the deeplink like this?
app://idkhowthisworks?access_token=<session_id">

I mean the session_id is long-lived and just there in plain-text. Isn't this an attack vector?

---

iirc, I think you recommended before to use a single-use / one-time token for cases like these when the session_id isn't accessible via the HTTP cookie.
i.e. if separate origins: #1071 (comment) (I can't find definitive proof that you mentioned this last year, but my memory recalls you said this somehow)

So maybe a better flow for here would be?

• Server /api.example.com/oauth/github returns a redirects for the webview to: app://idkhowthisworks?access_token=<one_time_token>
• App receives webview url with this deeplink. And gets access_token
• App makes a separate request to api.example.com/onetime-token?token=<one_time_token>?
• Server checks one_time_token and Sets-Cookie. Authed ✅

[pilcrowonpaper]

Probably not. At least in mobile devices, it's possible to intercept those deep links and steal the embedded token. OAuth prevents this using PKCE and it might be smart to implement something similar.

[Blankeos]

Interesting. So this is insecure either way... Can you elaborate on the PKCE approach btw?

Here's what I got from your reply + from searching up how PKCE works:

I guess before anything else... The client creates:

• code_verifier=xyz123 - never leaves the client
• code_challenge=hash(code_verifier) - sent to the server.

Then these are the 3 endpoints involved for the flow:

1. /initiate?code_challenge — generates a state and saves state+code_challenge to db/redis. Redirect to GitHub, then /callback.
2. /callback?code&state — generates temp_code and saves state+code_challenge+temp_code to db/redis. Return temp_code to client via deeplink (app://idk?temp_code).
3. /token?temp_code&code_verifier — client exchanges the temp_code + code_challenge: hash(code_verifier) db/redis query to validate auth. Then does Set-Cookie session. ✅ Done.

I guess the key PKCE behavior here is that code_verifier never leaves the client, so it can never be intercepted even with a interception of the deeplink. Is this right?

[pilcrowonpaper]

Almost, the code verifier is sent at step 3 in your list.

1. The client generates a code verifier (state too but not 100% necessary if you have PKCE, just a good fallback).
2. The client sends the code challenge hash(code_verifier) to server.
3. The server authenticates the user and returns the authorization code to client. The code challenge is bound to the authorization code.
4. The client exchanges the authorization code + code verifier for the PKCE.

Because step 4 is done through HTTPS and encrypted, the only vulnerable step is step 3.