## Frontegg as IDP via OIDC

Hosted login with OpenID Connect (OIDC) is a secure and flexible authentication and authorization protocol that allows organizations to delegate their user authentication to a trusted identity provider (IdP). OIDC is built atop OAuth 2.0, providing additional identity verification and access control features.

Prerequisites
This capability is fully supported via **Frontegg Hosted Login**. If you are using Frontegg's embedded login, then Social and SSO login methods **will not** redirect the end user to the 3rd party application out of the box.

### Common use cases

Since OpenID Connect (OIDC) streamlines user authentication across various platforms, you can leverage its benefits in multiple ways. For example:

#### Unified identity for documentation and support portals

OIDC allows users to access documentation and support portals via the same user identity. This unified login process eliminates the need for multiple credentials, simplifying access and improving the user experience across these essential resources.

#### Shared identity across applications

For organizations offering multiple applications, OIDC enables a single identity to be used across all platforms. This integration facilitates seamless navigation and interaction with different applications, reducing login fatigue and promoting user engagement.

#### Internal applications with shared identity

OIDC also benefits internal operations by allowing the same identity to be used across various internal applications. This approach streamlines employee access to intranets, HR systems, and other internal tools, simplifying credential management and enhancing security.

### Set up Frontegg as IDP via OIDC

For the sake of this tutorial, we will use the [OIDC playground](https://openidconnect.net/) as our **3rd party service**. The OIDC playground is a great tool to test and debug your OIDC flows.

Note that Frontegg implements OIDC (OpenID Connect) by default as part of its hosted login offering.

1. Go to **Authentication → Login Method**, and under your **Hosted Login** configuration, ensure that:
  - Hosted login is enabled.
  - The redirect URL of the service provider (in this example `https://openidconnect.net/callback`) is added within the **allowed redirect URLs**.
2. OpenID Connect endpoints can be found under [ENVIRONMENT] → Authentication → SSO → Identity Provider → OpenID Connect Endpoints.


If you have a [custom domain](/ciam/guides/env-settings/custom-domain) configured for the environment, you will see a `Use custom login` toggle. This feature simply allows you to easily copy the endpoints with your Frontegg or custom domain.

![oidc](/assets/oidc.428b5e6cb6258fd0f7716bcf849d1555b9880bc838381570554cb8383fba2ed3.7e3aa641.png)

1. **Client ID and Client Secret** - When configuring Frontegg as your OpenID Connect identity provider, you will also need to complete the **Client ID** and **Client Secret** fields:


![oidc](/assets/oidc-2.f43f8ecf92ae09ff975a39f79fd5d6cfb56514be236117db479bac68ea355949.7e3aa641.png)

In general, these credentials are the **Client ID** and **API key** located under your environment's **Keys & Domains** section, as shown in the screenshot below:

![oidc](/assets/secrets.7dc76cab2091f311e280b8a935a4ed4f79da114a217b44fd4e9954d534479f98.7e3aa641.png)

If you have a single application, the values you should use for the fields are taken from your **Keys & domains**. If you have multiple applications, you must configure the connection for a **specific application**. In that case, go to your Applications tab and fetch the **ID** and **API key** of that specific app, as shown here:

![oidc](/assets/app-page.b6f226e62fed3333fdc7c3a4a87b8c369954e25dcee4afeb93758095e6f9d29b.7e3aa641.png)

br
Multi-apps setup
Using Frontegg as an OIDC Identity Provider is supported only when a default application is defined in the environment.
If multiple applications exist and no default is set, we recommend using **OAuth2** instead, as OIDC may encounter audience `(aud)` verification issues in such cases.

br
 
4. **Token validation** - After running the flow on your 3rd party client and obtaining your Frontegg `id_token`, the JWT should be validated with a `jwks` and result in a **valid user** response.