notifications

[dickhardt]

There are a number of scenarios where the RP wants to notify the OP:

• the RP would like the OP to perform a command

  • metadata has changed and the RP is requesting the OP perform a metadata Command
  • the RP is not sure it has the correct account information, and wants the OP to perform an audit_tenant Command

• the RP has completed an asynchronous command and is notifying the OP that the Command has completed and its result

Other scenarios may come up.

For the RP to send a Notification, the OP provides a tenant specific notification_endpoint in its metadata. If the client is unable to authenticate to the OP, the notification_endpoint MUST have enough entropy to prevent it from being guessed, and should update the notification_endpoint on a regular basis. The notificaiton_endpoint is opaque to the RP. The notification_endpoint MUST represent context for the OP to know which RP is calling, and which tenant it is about.

The RP does a POST to the notification_endpoint and SHOULD authenticate if it can. The JSON payload

{
   "client_id": "asdas",
   "notification": "command_requested",
   "command": "metadata"
}

{
   "client_id": "asdas",
   "notification": "command_completed",
   "command": "delete",
   "jti": "sadh873hsjad",
   "response": {
       "sub": "12434",
       "tenant": "12323123",
       "account_state": "unknown",
   },
}

[mcguinness]

If the client is unable to authenticate to the OP, the notification_endpoint MUST have enough entropy to prevent it from being guessed

I have concerns with this level of protection for completing an asynchronous command. Anyone who obtains the URL & JTI can post responses such as saying a user was deprovisioned. I'm OK with high entropy URL for RP hinting (best effort and goal is minimize abuse), however completing a async command seems different IMHO and needs higher assurance. Maybe the OP needs to poll for completion if there isn't a viable way for the client to authenticate.

[dickhardt]

If someone can get the JTI and a high entropy URL then they have some pretty good access already.

Not clear what you think the attack is -- if the OP wanted to de-provision a user, then the attacker is saying the user was de-provisioned, even if the system did not de-provision? Or the attacker says the de-provision failed so the OP tries again?

This is just a notification of the result of a command the OP sent.

[mcguinness]

The notification_endpoint is an OP endpoint so I would expect like other OP endpoints it would be published in the /.well-known/openid-configuration metadata. Making this endpoint's URL have high entropy doesn't seem like it would add value if the endpoint is publicly discoverable.

In my experience, the jti claim is a fairly public value and logged everywhere. Its a base field in a JWT toolkit, where as access tokens or code a usually hashed before logging so the raw values are not useful for protocol messages. Its not treated as a sensitive value like a secret, token, or PII. There are multiple ways an attacker could get this value by just getting access to a log for example. If an attacker can tell the OP that an async command was successful such as unauthorize then it could trick the OP and security teams that use the OP as remediation for security incidents into thinking remediation actions were performed but in reality they weren't an attacker still has backdoor access.

The OP also needs to mitigate the risk of a bot attacking the unauthenticated endpoint with random JTIs and ensure that rate limits are not exhausted so that legitimate RP requests can be processed. I have seen many DOS attacks on OAuth endpoints in a previous life and the challenge was always how to isolate legitimate requests for public clients. An attacker can DOS the notification_endpoint as part of a multi-stage attack so that the OP can't remediate an attack against the RP which was the real target.

We could treat all these as edge cases but my concern was just that OP Commands is establishing a critical control plane that was missing between the OP and RP and critical workflow can be attacked just with knowledge of the jti.

[dickhardt]

The proposal specifies the notification_endpoint is only shared in the metadata command request. The notification_endpoint SHOULD NOT be in the /.well-known/openid-configuration metadata.

The OP SHOULD generate a new notification_endpoint value when it sends a new metadata command request. It is like a Slack webhook or other high entropy webhook. Perhaps I was not clear that the notification_endpoint was in the OP Command metadata request?

To further prevent nefarious posts, a command completion notification MUST contain the jti -> this is another layer of abuse prevention.

[mcguinness]

Thanks for the clarification, the text "OP provides a tenant specific notification_endpoint in its metadata" wasn't clear that you were intending this to be only the metadata command and not the OP's well-known configuration metadata.

Exchanging this value via a metadata command does enable the OP to have a RP specific endpoint so that should help a lot with abuse as you can bucket on client_id.

To further prevent nefarious posts, a command completion notification MUST contain the jti -> this is another layer of abuse prevention.

Yes, but the OP may need to make a DB call or other RPC to resolve the jti which is why its rate-limiting the endpoint.

It would add more complexity to the solution but the RP could return a public key in its metadata command response that the OP captures during bootstrap and uses to validate a RP POSTed notification command responses. This would be somewhat similar to DPOP in that the key is registered at runtime. This can be layered ontop of your proposal and the decision can be up to the OP if it wants to require proof of possession or not for notification responses. Since we can add this when needed without changing the pattern you propose I am OK with deferring this and getting more 👀 on the proposal.

[dickhardt]

Doing a key exchange would remove the entropy requirement.

Reminder that it's not an issue for confidential clients as the client SHOULD authenticate if it has credentials.

[brockallen]

What's the HTTP response to the RP sending this to the OP? I ask because doesn't that need to be a 202 in and of itself, given that the OP is about to kick off a bunch of async calls back out to the RP? Or do you expect those calls back to the RP to complete within the duration of this initiating call from the RP to the OP?

[dickhardt]

I was thinking it would be a 200 response unless an error. The OP is acknowledging receipt of the notification.

I view a 202 response is used when the server needs to differentiate from a 200 response.

[brockallen]

A 202 or 204 seem more appropriate then (if you're worried about the HTTP police)... but I don't think it matters in practice.

[dickhardt]

I'd prefer sending some JSON response rather than no content -- but a 204 could be ok.

[dickhardt]

Updated thinking per https://lists.openid.net/pipermail/openid-specs-ab/2025-April/010749.html

1. create new commands for each async version of a command, IE delete and delete_async

2. the OP includes an opaque parameter for one time use in each async command and in metadata command

3. the RP would use this parameter to send the result of an async command, and to request the OP to issue a new metadata command when the RP's metadata has changed

This parameter serves two purposes:

1. provide the context to the OP of the call from the RP

2. authenticate the RP to the OP

3. signal to the RP that the OP wants and accepts a callback

There are a couple proposed mechanisms:

1. the parameter is an opaque URL that embodies the context

2. the parameter is an opaque token that is passed to a static endpoint at the OP that is defined in the OP metadata

An alternative would be to not have a parameter and that client uses client credentials and authenticates posting data to a static endpoint. Currently we do not require the RP to have credentials at the OP which I view as a desirable feature.

Note that supporting notifications is optional for both the RP and the OP.

[dickhardt]

In person polling was overwhelmingly opting fro a fixed URL and an opaque access token