In the context of OAuth2 / OIDC, Dependency-Track's frontend acts as _client_ while the API server acts as _resource server_ (see [OAuth2 roles](https://tools.ietf.org/html/rfc6749#section-1.1)).
Refer to the [Configuration]({{ site.baseurl }}{% link _docs/getting-started/configuration.md %}) and [Docker deployment]({{ site.baseurl }}{% link _docs/getting-started/deploy-docker.md %}) pages for instructions. The “bundled” Docker image and "Classic" Dependency-Track deployments using solely the [executable WAR]({{ site.baseurl }}{% link _docs/getting-started/deploy-exewar.md %}) are not supported!
> **NOTE:** the front-end will *not* display the OIDC login button if the Dependency-Track service is unable to connect to your OIDC server's `.well-known/openid-configuration` endpoint. The server logs can help you identify whether this is an issue with firewall rules, internal TLS certificates, or other errors which may be preventing that communication.
> Before v4.3.0, Dependency-Track exclusively used the `/userinfo` endpoint of the IdP to get user information.
> Since v4.3.0, [ID tokens](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) are validated and evaluated as well. They even take precedence over `/userinfo`,
> which means that Dependency-Track will no longer request the `/userinfo` endpoint if all required claims
If you find that the provider of your choice does not work with Dependency-Track, please [file an issue](https://github.com/DependencyTrack/dependency-track/issues).
For a complete overview of available configuration options for both API server and frontend, please refer to the [Configuration page]({{ site.baseurl }}{% link _docs/getting-started/configuration.md %}).
OIDC integration with Azure Active Directory requires you to register Dependency-Track as an app in your tenant, see [Azure Active Directory app registration](#azure-active-directory-app-registration).
The `alpine.oidc.client.id` contains the Application ID of the app registration, and the `alpine.oidc.issuer` contains the Directory (tenant) ID.
- A trailing wildcard (`*`) was required when using frontend v1.3.0-v4.3.0, in order to support [post-login redirects](https://github.com/DependencyTrack/frontend/pull/47)
- Starting with v4.4.0, the trailing wildcard is no longer necessary
- Web Origins: `https://dependencytrack.example.com`
2. To be able to synchronize team memberships, create a _protocol mapper_ that includes group memberships as `groups` in
the `/userinfo` endpoint:
* Mapper Type: `Group Membership`
* Token Claim Name: `groups`
* Add to userinfo: `ON` (optional for Dependency-Track v4.3.0 and newer)
* Add to ID token: `ON` (for Dependency-Track v4.3.0 and newer)
3. Create some groups, e.g. `DTRACK_ADMINS` and `DTRACK_USERS`:
4. Verify that all required claims are present in the `/userinfo` endpoint
- Acquire an access token for a user and call `/userinfo` with it
- You can temporarily set _Direct Access Grants Enabled_ to `ON` in the client settings to enable the [Resource Owner Password Credentials Grant](https://tools.ietf.org/html/rfc6749#section-4.3)
7. Use the _OpenID_ button on the login page to sign in with a Keycloak user that is member of at least one of the configured groups. Navigating to _Administration -> Access Management -> OpenID Connect Users_ should now reveal that the user has been automatically provisioned and team memberships have been synchronized:
> Dependency-Track associates every OpenID Connect user with their subject identifier (`sub` claim of the access token) upon first login.
> If a user with the same name but a different subject identifier attempts to log in via OIDC, Dependency-Track will refuse to authenticate that user. This is done to prevent account takeovers, as some identity providers allow users to change their usernames. Also, uniqueness of usernames is not always guaranteed, while the uniqueness of subject identifiers is.
