Integration Comparison

logi offers four ways for an RP (Relying Party) to add SSO to its own service. Each method shares the same logi user accounts / scopes / token system; they differ only in the entry path up to the point where the user scans the QR.

At a glance

Method	RP implementation cost	User experience	Suitable scenario	Security model
1. Standard OAuth Code	0 (just a redirect URL)	Navigate to the logi page → sign in → return automatically	General web RPs, a first integration	confidential or PKCE public
2. Device Flow (RFC 8628)	Medium (implement start + polling)	Show a QR on the RP page + completes automatically via polling	Must keep the page (the Naver pattern), CLI / TV / IoT, in-app browsers	confidential or public (RFC 8628 §3.4)
3. Widget SDK	Low (script + div)	An iframe widget inside the RP page	Fast integration, framework-agnostic, limited design control	confidential or public + PKCE, widget_origins allowlist
4. Mobile SDK (planned)	Medium (native SDK)	Native calls from your own UI	Native iOS / Android RP apps	TBD

Decision tree

flowchart TD
  Start([RP integrates logi]) --> Mobile{Native<br>mobile app?}
  Mobile -- Yes --> MobileSDK[Wait for the future mobile SDK<br>or WebView + standard Code Flow]
  Mobile -- No --> StayOnPage{Can the user<br>leave the RP page?}

  StayOnPage -- Yes (redirect allowed) --> StandardCode[1. Standard OAuth Code<br>simplest]
  StayOnPage -- No (must keep the page) --> Speed{Fast integration vs<br>UI control?}

  Speed -- Fast integration first --> Widget[3. Widget SDK<br>script + div]
  Speed -- Direct UI control --> Device[2. Device Flow<br>RFC 8628]

  StandardCode --> Done([Implementation complete])
  Widget --> Done
  Device --> Done
  MobileSDK --> Done

Recommendations by scenario

"I want to add SSO to a general web service"

→ Standard OAuth Code Flow. It is the simplest. The RP only needs to register a redirect_uri. On desktop, a QR appears automatically on the right of the /oauth/authorize page; on mobile, the logi app opens automatically via a Universal Link.

"I need SSO right before payment, but the user must not leave the page"

→ Device Flow. Show a QR in a modal on the RP payment page and poll. When the user approves in the logi app, the RP backend receives the token, the modal closes automatically, and payment proceeds as-is. The Naver-style 'PC ↔ mobile authentication' pattern.

"I want to finish quickly with one line of frontend"

→ Widget SDK. <script src="https://embed.1pass.dev/widget.js"> + <div data-logi-qr ...>. It mounts within 5 minutes. The RP backend only needs to exchange the received code at /oauth/token.

"It has to work even in the KakaoTalk in-app browser"

→ Device Flow. In-app browsers don't bring up Universal Links, so the standard OAuth redirect breaks. The Device Flow needs no redirect, so it works correctly even in-app.

"Smart TV / Apple TV / set-top box / CLI tool"

→ Device Flow. In fact, RFC 8628 was designed for exactly this scenario. The logi CLI (logi login) also uses the same device flow (see the CLI docs).

"An iOS or Android native app"

→ Wait for the future mobile SDK. For now, use the standard Code Flow + a WebView, or ASWebAuthenticationSession (iOS) / Custom Tabs (Android). See the Universal Links integration guide.

Can I use several together?

Yes. The same RP can use the standard Code Flow on desktop, the Device Flow as an in-app browser fallback, and the Widget SDK for an embedded payment modal — all at once. On logi's side, everything is handled within the same OAuth Application (client_id) — you just need to fill in both redirect_uris and widget_origins when registering the application in the console.

The payload / permissions of the issued token are identical no matter which path it came in through — you can distinguish the authentication path via the amr claim of the id_token (a future spec).

Next steps

• Standard Authorization Code Flow — the most common
• Device Flow (RFC 8628) — keep the RP page
• Widget SDK — the fastest integration
• QR login (app push approval) — the QR option on logi's /oauth/authorize