Recommended auth flow for third-party browser-based account linking?

[InHotWater]

Hi Light team,

I’m experimenting with the SDK and exploring a Plex audiobook Tool for Light Phone III.

The intended user experience is very Light-like:

• Account/setup happens outside the phone if possible
• The phone UI stays minimal
• The Tool opens to the current audiobook / simple library controls
• Audiobooks stream or download from the user’s own Plex server

The main thing I’m trying to understand is the recommended SDK pattern for third-party account authentication.

Plex uses a browser-based PIN / OAuth-like flow:

1. The app requests a PIN/code from plex.tv
2. The user approves the app in a browser at app.plex.tv/auth
3. The app polls Plex for the resulting token
4. The app uses that token to list the user’s Plex servers, libraries, and audiobook files

In a normal Android app, I’d launch the browser with an ACTION_VIEW intent. But from what I can see, the current Light SDK intentionally blocks direct Intent / startActivity access from Tool code.

So my questions are:

• What is the recommended Light SDK approach for an external account-linking flow like this?
• Should Tools eventually be able to request opening an external URL through a Light-approved SDK API?
• Is the intended pattern instead that account setup happens in the Light Dashboard, with config/token data synced to the Tool?
• If Dashboard setup is the preferred path, is there or will there be an API for securely passing Tool configuration/secrets to the device?
• Is it acceptable for a Tool to poll a third-party auth endpoint after the user approves access in a browser/dashboard?
• Are there examples planned for account-linked Tools?

I’m not trying to bypass the Light constraints. I’m trying to fit into them cleanly. For this use case, Dashboard-based setup would actually be ideal if the SDK supports it: the user connects Plex on a computer, then the phone just gets the minimum config it needs to browse/listen.

Thanks. The SDK is exciting, and this kind of guidance would help a lot for Tools that integrate with existing services.

[dupontgu]

Hi! Sorry for taking so long to get to this - we were actively thinking through it. I think the tl;dr is - anything browser-based should happen on a companion device (desktop or smartphone) for now. We set that precedent with the dashboard and it's simplest for everyone to keep it that way.

So to answer your questions:

What is the recommended Light SDK approach for an external account-linking flow like this?
Are there examples planned for account-linked Tools?

Nothing yet, but we will!

Should Tools eventually be able to request opening an external URL through a Light-approved SDK API?

not exactly, we think you should be able to launch the url on a nearby device as smoothly as possible. For now, we recommend putting
up a QR code to scan.

Is the intended pattern instead that account setup happens in the Light Dashboard, with config/token data synced to the Tool?
If Dashboard setup is the preferred path, is there or will there be an API for securely passing Tool configuration/secrets to the device?

Not the cloud-based dashboard, but we're going to be releasing our File Manager soon, which will behave kind of like a dashboard over your local network. So you can upload/download/change configuration directly over WiFi. I talk about it a bit more in my announcement from last week.

Is it acceptable for a Tool to poll a third-party auth endpoint after the user approves access in a browser/dashboard?

Totally!

We're also thinking about how we could make something like OAuth work directly the http server that's going to be running on the device to host the File Manager. We're thinking it could be like:

Tool puts up QR code for Oauth -> User scans on their webcam and authenticates on the computer -> the baked in callback url for OAuth points to the local IP address of the phone so the token gets passed directly to the file manager, and dropped into the tool's private inbox. We're gonna test it out.

[InHotWater]

Thank you!

I really appreciate that the team took the time to think this through carefully, especially knowing this SDK/community work is not exactly anyone’s day job.

The direction makes a lot of sense to me: keep browser/account flows on a companion device, keep the phone experience minimal, and use QR/polling or eventually the local File Manager/private inbox as the bridge. That gives me a very workable path for the Plex Audiobookshelf-style tool and possibly a couple other tools as well.

Thanks again for being so open about the intended direction.

[wsturgiss]

Hey, just thought I'd let you know I'm also looking to build a plex audio player - basically looking to replicate basic plexamp functionality in lightOS. I'm not a mobile developer (I've been doing web dev for a decade) but I'm getting up to speed. Maybe between those of us interested in Plex audio playback we can collaborate on a tool to get this working.

[InHotWater]

This is great. Yes, I think the more the merrier when it comes to dev'.

I have a working prototype that connects to Plex, authenticates via a companion-device flow, stores the Plex token locally, and can browse servers, libraries, recently added audiobooks, search results, and track/file metadata.

As you can see from the feedback above, I moved moved away from baked-in credentials toward the phone-side pairing plus local token storage, with a path for future File Manager/private-inbox config. Playback is not wired yet, but the Plex discovery and audiobook selection part is in place.

The next part will be background audio, lock-screen media controls, and offline downloads.

[wsturgiss]

Yeah I saw that conversation. I think it should be relatively easy, it sounds somewhat similar to the pairing auth flow that you see in plex apps in smart TVs - where a secondary device does all the heavy lifting and the TV mostly just has a code to confirm its the right device.

It would be funny if we got offline downloads working reliably in any length of time under a decade...that would be faster than Plex themselves did it xD

[InHotWater]

Today I updated the app's Plex auth flow to match the Light devs’ recommended companion-device pattern. Yes, it's just like you said with smart TV's, etc.

The app now:
Creates a Plex pairing code on-device
Shows a QR code for https://plex.tv/link
Displays the short Plex code as fallback
Polls Plex until the user approves access
Saves the Plex token locally

Testing now: QR/code pairing from another device, then confirming the app stays connected and can load Plex servers/libraries/audiobooks after restart.

[wsturgiss]

Nice! Are you aware of phono? They already have some streaming tools working apparently. Haven't used it yet, but just noting there may be some duplication of effort here. https://github.com/jonathancaudill/phono

[wsturgiss]

Note on phono, it breaks TOS for some other audio streaming services it uses, so it probably won't ever be light-approved. Sounds like a separate plex tool is still a good idea.