# Octet LFA

A location factor for sign-in.

LFA (Location Factor Authentication) adds a check that a password, passkey, or
OTP cannot make: whether the user is physically inside the region your policy
requires. The user proves presence with the Octet Location app on their phone.
The proof is hardware-attested and resistant to spoofing, and no raw coordinates
leave the device. Your application receives a region verdict, nothing finer,
delivered over standard OIDC.

LFA is built on the [Octet SDK](/docs/). The SDK produces and verifies the proof
itself: the on-device pipeline, the hardware attestation, the anti-spoof
verdicts, the region model. LFA turns that proof into an authentication factor.
It wraps the proof in OIDC, applies your policy, and binds it to one of your
users on one enrolled phone.

:::note[Private preview]

LFA is in private preview. The phone app ships on iOS and Android, geofences are
country-level, and clients are registered by the Octet team
([hello@octetproof.com](mailto:hello@octetproof.com)). There is no self-service
sign-up yet. Identity brokers (Okta, Microsoft Entra ID, Auth0) are supported
via signed authorization requests
([RFC 9101](https://www.rfc-editor.org/rfc/rfc9101)). See [Okta](/docs/integration/okta/).

:::

## Pick a starting point

- **Evaluating LFA** -> [How a login works](/docs/concepts/how-a-login-works/)
- **Integrating now** -> [Prerequisites](/docs/getting-started/prerequisites/), then the [Quick Start](/docs/getting-started/quickstart/)
- **Deciding what to enforce** -> [Policies](/docs/concepts/policies/)
- **Users replacing or losing phones** -> [Device lifecycle](/docs/concepts/device-lifecycle/)
- **Looking up an endpoint, parameter, or claim** -> [OIDC Reference](/docs/reference/oidc/)

## What this documentation covers

- [**Getting Started**](/docs/getting-started/prerequisites/). What you need before the first login, and a complete login end to end.
- [**Concepts**](/docs/concepts/how-a-login-works/). The login flow, policies, the device-to-user binding lifecycle, and what LFA stores and never stores.
- [**Integration Guides**](/docs/integration/direct-oidc/). Direct OIDC integration for any authorization-code stack, and identity brokers (Okta, Entra, Auth0) via signed authorization requests.
- [**Reference**](/docs/reference/oidc/). Endpoints, protocol requirements, parameters, claims, and errors.
- [**Troubleshooting**](/docs/troubleshooting/faq/). Indexed by the error you see.

## Where LFA stops

- **Not a source of identity.** LFA is delivered as an OIDC provider, but it
  establishes where the user is, not who they are. Through
  [device binding](/docs/concepts/device-lifecycle/) it also establishes possession of
  the enrolled phone. Your primary IdP or your own login proves who the user is:
  you tell LFA which of your users is signing in, and LFA never sees a password
  or a profile. [Trust & Privacy](/docs/concepts/trust-and-privacy/) lists what is
  stored.
- **Not a tracking service.** The phone never uploads coordinates. The proof
  carries a region verdict ("in GB") and the cryptographic material to check it.
  Nothing else.
- **Not a heuristic.** IP geolocation infers a location from network routing and
  is often wrong. LFA verifies it. Every proof is rooted in the phone's secure
  hardware (see [device attestation](/docs/concepts/device-attestation/) in the
  SDK docs), and a spoofed or tampered proof is rejected, not scored.