Support OIDC for internal auth

[jannef]

Managing internal auth with authorized_keys is a needless complication, that if anything, leads to security compromises due to administrative overhead. Since JWT bearer auth is now supported, there is no reason to use such a legacy way to configure authentication.

Instead, internal auth should be configurable by simply providing a reference OICD discovery document. Implementing it this way and just trusting organisational IDP automatically supports basic security features such as MFA, key rotation, indentity protection and conditional access.

[reinkrul]

For API clients as well? I think APIs usually implement some sort of "API token" approach (e.g. Github's application tokens), as OpenID Connect is meant for use cases when there's a user involved?

Or, would you have your XIS/application (that calls the Nuts node) forward/use the OIDC token from your Identity Provider for authentication at the Nuts node's internal APIs as well?

We're in the process of implementing a user (Verifiable Credential) wallet, which will probably support OIDC for user authentication. Maybe we should take API authentication into account as well (1 solution to rule them all).

@woutslakhorst

[jannef]

I was trying to specifically write about interna-facing API authentication, as discussed here: https://nuts-node.readthedocs.io/en/docs-rewrite-recommended-deployment/pages/integrating/api-authentication.html#configuration

In case of M2M communication, the token would probably be acquired using an OAuth2.0 flow, but still, it would be issued by an Idp. Such standard implementation would nicely integrate with all major public cloud identity platforms. Secret management in public cloud could then be entirely off-loaded to services such as Azure Managed Identities or AWS IAM Roles.

I think APIs usually implement some sort of "API token" approach (e.g. Github's application tokens)

This is the case for multi-tenant applications, where configuring the trust relationship between Idps is not feasible. A nuts node however is not a multi-tenant application and it would be much preferrable to acquire M2M access tokens using OAuth2 Client Credentials Grant.

[woutslakhorst]

It would be a nice additional feature. Making it the only API authentication scheme would make it more complicated for those not using an IDP. It's less of a burden to add the current auth for IDP compatible users than it's for the others to add an IDP.

[jannef]

It would be a nice additional feature. Making it the only API authentication scheme would make it more complicated for those not using an IDP. It's less of a burden to add the current auth for IDP compatible users than it's for the others to add an IDP.

I agree, this should be just an option.

[reinkrul]

We discussed this feature as something we'd like. It has a big advantage over the current auth methods, as it allows you to pass down the authenticated end-user for (audit) logging purposes and authorization. For instance:

• If an administrator creates a new care organization/client, which in turn creates a subject in the Nuts node, the administrator is logged as the user performing the action inside the Nuts node
• Administrative applications don't have the permissions to create access tokens (and steal data)
• (EHR) applications don't have the permission to administer subjects (and break data exchange)

It would function as follows:

• Support OpenID Discovery; you point the Nuts node to the right OpenID Provider (well-known metadata URL)
• The caller acquires an access token from the Provider, after the user successfully logged into the caller application.
  • This is architecture-specific, in Microsoft Entra the "on behalf of" (JWT bearer token flow) is typically used: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow
• Only JWT access tokens are supported for now (as this feature proposal is driven by Entra), OAuth2 token introspection support can easily be added later if someone requires it.
  • Pro of JWTs: works even if OpenID Provider is slow/down
  • Pro of OAuth2 Token Introspection: suitable alternative, could be used if the all there is, is an OAuth2 Authorization Server instead of a OpenID Connect setup.
• Scopes can be used for authorization (scope assignment depends on the OpenID Provider/OAuth2 Authorization Server);
  • nuts.admin: manage subjects & discovery service activation
  • nuts.credential.issuer: issue and revoke credentials
  • nuts.application: request access tokens, searching on discovery services
  • nuts.authorizer: verify access tokens