Set up Lobyco IDP for your websites

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.

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.

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

Send the customer to the authorization endpoint

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.

Exchange the code for tokens

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.

Call the APIs with the access token

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

Authorization: Bearer {ACCESS_TOKEN}

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.

Mobile app authentication — the same identity provider in the app, and the external-provider mode.

​Before you start

​The flow

​Send the customer to the authorization endpoint

​Exchange the code for tokens

​Call the APIs with the access token

​Scopes

​Validate tokens on your backend

​Failure and edge cases

​Related

Before you start

The flow

Send the customer to the authorization endpoint

Exchange the code for tokens

Call the APIs with the access token

Scopes

Validate tokens on your backend

Failure and edge cases

Related