feat(auth): implement tokenlogin endpoint

[Junjiequan]

Description

This PR introduces a new authentication endpoint that allows users to log in using an ID Token issued by a trusted external OpenID Connect (OIDC) provider.

New endpoint:

POST /auth/oidc/token

Accepts:
{ idToken: string }

The endpoint validates the provided ID Token with the trusted external OIDC provider and, upon success, authenticates the user in SciCat and returns a SciCat JWT.

Refactors

New OpenID Client Module

A dedicated openid-client module has been created containing:

• OidcClientService
• OidcAuthService

The goal of this refactoring is to provide a single global OIDC client instance that can be reused across modules.
This is necessary because the same client is required by both the OIDC strategy and the token-based login flow.

Clear responsibilities

OIDC-related responsibilities have been separated to improve clarity and maintainability.

OidcClientService:

• Handles only OpenID Connect client discovery and instantiation

OidcAuthService:

• Contains application-level authentication logic
• Validates token sets
• Maps claims to user profiles
• Finds or creates users
• Returns authenticated user profile

OidcStrategy:

• Acts as a thin Passport adapter

New Feature - Rate Limiting

Rate limiting concept has been introduced using @nestjs/throttler. Currently it is applied only to the new endpoint POST /auth/oidc/token and the limit is set to 1 request per second per IP. If the limit is exceeded, the request will be rejected with HTTP 429 until the rate limit window resets. This prevents excessive token generation and protects the authentication endpoint from abuse.

NOTE: No global throttling is applied to other endpoints.

Motivation

This endpoint is useful in scenarios where authentication needs to be performed by providing only a valid ID Token issued by an external OIDC provider, without going through the standard redirect-based login flow.

Tests included

• Included for each change/fix?
• Passing?

Documentation

• swagger documentation updated (required for API changes)
• official documentation updated

official documentation info

[jl-wynen]

There is a typo in this file name: cilent instead of client.

[Junjiequan]

nice tach, it's fixed

[jl-wynen]

There is an alternative to adding a completely new client config in scicat. We can simply add an additional authorized party like so:

Suggested change

	this.client = new issuer.Client({
	client_id: this.oidcConfig.clientID,
	client_secret: this.oidcConfig.clientSecret,
	});
	this.client = new issuer.Client({
	client_id: this.oidcConfig.clientID,
	client_secret: this.oidcConfig.clientSecret,
	},
	undefined,
	{
	additionalAuthorizedParties: [publicClientId]
	});

where publicClientId is the ID of the public IdP client.

With this change, scicat will allow ID tokens from that public client as long as the audience (aud) includes the scicat client:

{
    aud: [this.oidcConfig.clientID, ...],
    azp: publicClientId,
    ...
}

Keycloak (and probably other OAuth providers) can be configured to create tokens like this.

I tested this with my little setup and it works. But I did not propose a complete solution here because I don't know how to add extra config options.

[omkar-ethz]

I also had the impression from the description

allows users to log in using an ID Token issued by an external OpenID Connect (OIDC) provider.

that the goal of the PR was to exchange ID tokens from arbitrary OIDC providers. This sounded quite risky - but looking at the code, we still only trust a single pre-configured client ID. And the PR seems more about refactoring, and introducing the new endpoint that lets one exchange the OIDC token for a SciCat JWT.
Approving as it LGTM.

[Junjiequan]

@omkar-ethz

Yes, token login endpoint allows only exchange for single pre-configured client.

The next step what we at ESS think is worth to implement is allowing multiple TRUSTED providers to exchange SciCat JWT token. Multiple providers is useful when multiple services depend on scicat as a central backend