Current status of this discussion

Implementing XOAUTH2 for Keycloaks outgoing Emails described in #17432 made several ideas and improvements visible. The topic was discussed with serveral participants of the Keycloak DevDay 2025 Hackathon. Needs further feedback, everone is welcome.

Problem description

The abstract topic is: The IAM System has several reasons to send a message to the user of an identity. Keycloak provides Email for several Use-Cases via SMTP-Protokoll which allow sending good old E-Mails to users. There are several improvements in every step.

From a user of an identity, there might be different things a message can be sent to: message-handle

• E-Mail
• Mobile phone Number
• Chat/Messanger-Handle
  -- Slack
  -- ...

When looking into the Details of each of the message-handles there are the protocols these handles accept:

• SMTP
• Some HTTP-Service that allowes sending messages to these handles, probably very specific to a provider

Each protocol supports different authentication mechanisms

• Password
• Token

For Token based authentication mechanisms we have different ways to gather a token. I would argue to stick to mechanisms that are meant to be used by a machine:

• Provide the token as is, no option to renew it. User is required to update the token before the token expires.
• Client Credentials Grant authenticate with Client Secret
• Client Credentials Grant authenticate with JWT
• Client Credentials Grant with other option to authenticate

Solution

Assumptions

1. Required functionality is not in the core-domain of Keycloak.
2. There is no standard the can be used throughout cloud providers
3. Not aware of something that can do all these things like a library or framework

Build some more explicit ways to allow extensions to the area

Things to keep in mind/requirements

1. Separate extensionpoints for creating/building the message and sending the message? Might be more complicated when the message has to consider restrictions of the way the message is sent? E.g. size restrictions, formatting rules, etc.; Some people during the hackathon have involved a content management system in the message building process.
2. Sending a message is a function for keycloak user and its attributes given a message. Maybe the message can be provided in a way that restrictions of the sending-mechanism can be applied: e.g. send an SMS has different properties than sending an email.
3. The configuration might be different per realm and might support different mechanisms depending on the users attributes
4. Provide some of the existing ways Keycloak supports as explicit implementations, but not try to make things composeable/reusable in the first place. An explicit list with explicit configuration per message-service could make sense.

This would create a dropdown with every message provider that Keycloak can find during startup

1. SMTP Password
2. SMTP Microsoft-XOAUTH2
3. SMTP Gmail-XOAUTH2
4. Azure-Message-Service
5. Google-Message-Service
6. AWS-Message-Service
7. ...

Each line is self-contained and complete. Behind the scenes there might be libraries or code shared that is part of Keycloak, but things are likely to be more complex than planned.

Any alternative ideas or recommendations? Maybe existing libraries? The available provider-SDKs might introduce a lot of dependencies :(.
Using the build feature might be useful similar to the db selection.