> ## Documentation Index
> Fetch the complete documentation index at: https://help.lobyco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up Lobyco IDP for your websites

> Sign customers in to your own websites with Lobyco IDP, using the OAuth 2.0 authorization code flow with PKCE.

If Lobyco holds your membership data and Lobyco IDP signs your customers in, your own websites can use the same sign-in. A corporate site or a web shop then shares sign-up, sign-in and the MyProfile page with the app. It calls the Lobyco APIs on the customer's behalf. This page is the flow your website implements. Your web developers do it, with a standard OAuth 2.0 library.

Lobyco IDP supports the OAuth 2.0 authorization code flow with PKCE. A public client, such as a single-page application, uses it without a client secret.

<Note>
  Use a standard OAuth 2.0 or OpenID Connect client library for your front-end framework rather than the raw protocol. Lobyco recommends it because the library handles PKCE, the redirects, token storage and silent renewal for you.
</Note>

## Before you start

Ask Lobyco to register the website as a public OAuth client in Lobyco IDP. Lobyco needs:

* The client name, that is your application's name.
* The redirect URIs: the exact URLs customers return to after signing in, such as `https://example.com/callback`.

You receive two values, `IDENTITY_BASE_URL` and `CLIENT_ID`.

## The flow

<Steps>
  <Step>
    ### Send the customer to the authorization endpoint

    ```http theme={"system"}
    GET {IDENTITY_BASE_URL}/oauth2/auth
      ?client_id={CLIENT_ID}
      &response_type=code
      &audience={AUDIENCE_1}+{AUDIENCE_2}
      &redirect_uri={CLIENT_REDIRECT_URI}
      &scope={SCOPE_1}+{SCOPE_2}
      &state={STATE_VALUE}
      &nonce={NONCE_VALUE}
      &code_challenge={CODE_CHALLENGE}
      &code_challenge_method=S256
    ```

    The customer signs in, or signs up, and authorises your application. Lobyco IDP sends the browser back to your `redirect_uri` with an authorization code. The scopes to ask for are under [Scopes](#scopes).
  </Step>

  <Step>
    ### Exchange the code for tokens

    ```http theme={"system"}
    POST {IDENTITY_BASE_URL}/oauth2/token
    Content-Type: application/x-www-form-urlencoded

    grant_type=authorization_code
    &code={AUTHORIZATION_CODE}
    &redirect_uri={REDIRECT_URI}
    &client_id={CLIENT_ID}
    &code_verifier={CODE_VERIFIER}
    ```

    The response carries:

    * `access_token`, for calling the Lobyco APIs.
    * `id_token`, the customer's identity, when OpenID Connect is enabled for the client.
    * `refresh_token`, for renewing the tokens, when the client is allowed one.
  </Step>

  <Step>
    ### Call the APIs with the access token

    Put the access token in the `Authorization` header of each request:

    ```http theme={"system"}
    Authorization: Bearer {ACCESS_TOKEN}
    ```
  </Step>
</Steps>

## Scopes

| Page | Scopes to request |
| - | - |
| Sign-in and sign-up | `openid`, `offline_access` |
| MyProfile | `openid`, `offline_access`, `profile`, `profile.edit` |

## Validate tokens on your backend

Which check your backend runs depends on the token type. A JWT access token is validated locally against the issuer's `jwks_uri`. An opaque access token is checked by calling the introspection endpoint, `/oauth2/introspect`.

## Failure and edge cases

The usual failure is a redirect URI mismatch. The `redirect_uri` must match exactly what Lobyco registered, including the scheme and the path. Otherwise Lobyco IDP refuses the request before the customer sees a sign-in page.

## Related

* [Mobile app authentication](/integration/get-started/mobile-app-authentication) — the same identity provider in the app, and the external-provider mode.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.