[BUG] API tokens disabled for ODIC users

[andrewmeyer]

Describe the bug
When IRIS_AUTHENTICATION_TYPE is set to oidc, the API Key field is completely absent from the "My Settings" page. This prevents OIDC-authenticated users from viewing or regenerating their API key, making programmatic/API access impossible for those users.
The root cause is in the settings page template, where the API key UI block is conditionally rendered only for local and ldap authentication types:

{% if config['AUTHENTICATION_TYPE'] == 'local' or config['AUTHENTICATION_TYPE'] == 'ldap' %}

https://github.com/dfir-iris/iris-web/blob/master/source/app/blueprints/pages/profile/templates/profile.html#L90C1-L107C32

The oidc case is not handled.

To Reproduce
Steps to reproduce the behavior:

1. Configure IRIS with IRIS_AUTHENTICATION_TYPE=oidc
2. Log in as an OIDC-authenticated user
3. Navigate to My Settings (top-right user menu → My Settings)
4. Observe that the API Key field is absent entirely

Expected behavior
The API Key field should be visible and functional for OIDC users, identical to the behavior for local and ldap users. API key access is a programmatic concern independent of the interactive authentication method — OIDC users have the same need for API access as local or LDAP users.

Desktop (please complete the following information):

• OS: Docker image
• Browser: Firefox
• Version: IRIS v2.4.29

Suggested fix
Either extend the condition to include oidc:

{% if config['AUTHENTICATION_TYPE'] == 'local' or config['AUTHENTICATION_TYPE'] == 'ldap' or config['AUTHENTICATION_TYPE'] == 'oidc' %}

Or remove the authentication type gate entirely, since there is no security justification for hiding API keys from any authenticated user class:

jinja2{% if current_user.api_key %}

Additional context
This also appears to impact local-only users without a OIDC link, provided the authentication type is OIDC.

[andrewmeyer]

If this is as simple as removing the if block in the template, I can open a PR this evening, but I did not want to presume that there was not an underlying reason for excluding remote users from API access

[andrewmeyer]

I can confirm that the API key in the DB is valid, so it seems fine to display it, this might have been a holdover from earlier situations where OIDC was half-baked