Login method restriction

By default, the logi login screen shows every available method: Apple/Google/Kakao SSO · email/password · the logi app (push approval · QR · app install). An RP can narrow this down so that only some of these are shown.

What this feature is

This feature simplifies the login screen UI. No matter which method a user signs in to their logi account with, the identity the RP receives (sub, profile) is the same — this is not a security boundary. For details, see Caveats.

Overview — what problem this solves

When an organization that uses only Google Workspace internally adopts logi, the login screen shows Apple, Kakao, email, and QR as well, which confuses employees. Such a B2B RP wants to surface only "Continue with Google".

logi provides two ways to do this.

Method	Where it applies	Enforced?
URL parameter provider	Per authorize request	Controls visibility only (not enforced)
Console setting	Permanent, per-app setting	Server-side enforced

The two work together: the console setting is the base, and provider only narrows within it (Precedence rules).

Method 1: URL parameter provider

Append a provider query parameter to the authorize URL. The value is a comma-separated list of login method keys.

https://api.1pass.dev/oauth/authorize
  ?client_id=logi_a1b2...
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fcallback
  &response_type=code
  &scope=profile+email
  &state=<32-byte_random>
  &code_challenge=<...>
  &code_challenge_method=S256
  &provider=google

To allow several methods, list them with commas — &provider=apple,google.

Login method keys

Key	What it shows on the login screen
apple	"Continue with Apple" SSO button
google	"Continue with Google" SSO button
kakao	"Continue with Kakao" SSO button (only when Kakao Web SSO is configured and allowed in the logi platform environment)
email	The email/password login form
app	The full logi app path — the Mac app / open-app card, push approval, QR login, and app install guidance

provider controls visibility only

provider is a parameter that only narrows which methods are shown on the login screen. It is not validated during authorize, and invalid values (e.g. provider=facebook) are ignored. To restrict methods permanently, use Method 2: Console setting.

Method 2: Console setting

Set this permanently in the app settings of the start.1pass.dev developer console, via the "Login method restriction" checkboxes.

1. start.1pass.dev → select your app → Settings
2. In the Login method restriction section, check the methods to allow (Apple/Google/Kakao SSO · email/password · the logi app)
3. Save

• Leaving all checkboxes empty (the default) surfaces every method (= allow all).
• This setting is enforced server-side. Unchecked methods are not only hidden from the screen but also blocked even if a user navigates directly to their login start path (the Apple/Google/Kakao web SSO start, the QR start, or the push approval start).

How it differs from the URL parameter

The console setting is the permanent per-app base, while the provider parameter narrows within that base on a per-request basis. When both are used, the intersection of the base and the parameter applies; if the intersection is empty, the methods are surfaced according to the console setting (the base) — see the precedence rules below.

Precedence rules

This is computed in three stages.

1. base = the console setting (allow all if empty)
2. effective = the provider parameter ∩ base — provider can only narrow. If the intersection is empty, it falls back to the base.
3. renderable = effective filtered by the current environment's availability (e.g. kakao is excluded in an environment where Kakao is not configured)

Console setting (base)	provider parameter	Actually surfaced	Explanation
(none = all)	google	Google only	The base is broad, so provider narrows it
apple,google	google	Google only	provider narrows within the base
google	apple	Google only	Empty intersection → fall back to base (does not lock out)
google	(none)	Google only	The base applies as-is
(none = all)	facebook	All	Invalid provider value is ignored

Fail-open behavior

logi never locks a user out of logging in.

• If provider contains an invalid value, it is ignored (no authorize error).
• If provider ∩ console setting is empty, methods are surfaced according to the console setting.
• If every method in the console setting is unavailable in the current environment (for example, only kakao is allowed but Kakao is not configured), it falls back to email login and shows an explanatory message.
• As a result, an empty login screen never appears.

Caveats

This is not a security boundary

Login method restriction only simplifies the screen; it does not change identity. No matter which method a user signs in to logi with, the sub and profile the RP receives are the same. Do not use it to distinguish users who came in via one method from those who used another, or to control access permissions.

• Even when provider is a single value, logi does not auto-redirect to that IdP — it always goes through the login screen (not supported in v1).
• Email/password (email) is also controlled for visibility only (UI-only). The context-free direct login path is not subject to server-side enforcement.

References

• Authorization Code Flow — where the provider parameter goes
• Web SSO (desktop Apple/Google) — the SSO start paths