Support validating credentials directly in admin API outside of self-service API

[tobias-urdin]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

Hello,

We have a bit of a strange use-case in that we need to verify the TOTP code for a user separate from the self-service flows, as of now that's not possible with any official Kratos API, so what we have is a micro service exposing a secure HTTP based API that reads directly from the Kratos database identity_credentials table to get the TOTP secret which is ugly but works.

typename = "totp"

SELECT ic.config
FROM identity_credentials ic
LEFT JOIN identity_credential_types ict
  ON ict.name = :type_name
WHERE ic.identity_credential_type_id = ict.id
  AND ic.identity_id = :identity_id

I can understand that this seems weird, but currently the TOTP credential alone cannot establish a session in the self-service login flow (and could arguably be considered a security issue even if configurable) as it's an assurance level increase and not a credential similar to password to establish AAL1.

I was thinking about how this could be solved or some kind of design, what if there was a admin API endpoint where you could actually perform validations against any kind of credential? That would make it more generic, admin API only and support even more integrations with third party systems (or legacy systems if you will) without exposing any security issues in the self-service API.

Thanks for taking the time to read all the way here, looking forward to any comments and ideas.

Describe your ideal solution

An admin API endpoint that can be used to verify password, TOTP and any other credentials for integration into other systems.

Workarounds or alternatives

The workaround for us is currently reading the TOTP config (and thus extracting the secret) from the identity_credentials table in the Kratos database.

Version

v25.4.0

Additional Context

No response