Authorization Grant in Webhook guideline

[sjaakd]

Omschrijving

Dag,

Wij (TNO / BRO) zijn druk bezig met de implementatie van cloud-events volgens het NL-GOV profiel . Dit is een jaar geleden gestart, echter lang gewacht op een IAM oplossing.

Welnu deze oplossing is er.

De standaard is onduidelijk hoe er met oAuth moet worden omgegaan. Logisch zou zijn dat de OPTIONS verzoek:

OPTIONS <Resource Owner OPTIONS Path from subscription> HTTP/1.1
Host: <Resource Owner OPTIONS Host from subscription>
Accept: application/json;q=0.9;*/*;q=0.1
Accept-Language: nl-nl,nl;q=0.9;en;q=0.1
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: <hostname of the event broker sending the OPTIONS request>
WebHook-Request-Origin: eventemitter.example.com
WebHook-Request-Callback: https://example.com/confirm?id=12345&key=...base64..
WebHook-Request-Rate: 120
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

ook de Authorization Grant zou retourneren:

HTTP/1.1 200 OK
Date: <timestamp of the request>
Server: <Resource Owner Server Identification>
WebHook-Allowed-Origin: eventemitter.example.com
WebHook-Allowed-Rate: 120
Access-Control-Allow-Origin: <Resource URI of the protected endpoint at the Resource Owner>
Access-Control-Allow-Methods: <Protected Resource Server allowed method, i.e. POST>
Access-Control-Allow-Headers: <Protected Resource Server allowed HTTP Headers, i.e. X-PINGOTHER, Content-Type>
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive 
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
	"access_token":"mF_9.B5f-4.1JqM",
	"token_type":"Bearer",
	"expires_in":3600,
	"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
	"example_parameter":"example_value"
}

De gebruiker behoeft dan alleen een callback URL en een secret te provisionen voor zijn client (naast de filters waarop de verzoeken gefilterd kunnen worden, volgens de 'interesse' van de client).

Echter, dit is volgens mij niet vastgelegd. Tenminste, ik kan het niet vinden.

Hoe kijken jullie hier tegenaan? Is dit een omissie?

Naam

No response

Email

No response

Organisatie

TNO / BZK

[edwinwisse]

Deze vraag staat op de agenda voor het volgende TO.

[adgerrits]

Weer even in CloudEvents gedoken dus geen garantie dat wat ik zeg klopt...
Even vooraf; het is denk ik goed om steeds expliciet te zijn over welk onderdeel van 'CloudEvents' het gaat. Het gaat hier om 1 van de 'optional specifications': HTTP 1.1 Web Hooks for Event Delivery (niet de Core Specification).
Daarin staat "The client MAY use any token-based authorization scheme. The token can take any shape, and can be a standardized token format or a simple key expression." maar ook "lean on the OAuth 2.0 Bearer Token RFC6750 model". Een van de CE-uitgangspunten is om zich te beperken tot wat nodig is en vooral niks te specificeren wat al bestaat (en soms meerdere vormen kent). Ik vermoed dat dit ook hier speelt.
"This specification defines a HTTP method by how notifications are delivered by the sender, an authorization model for event delivery to protect the delivery target, and a registration handshake that protects the sender from being abused for flooding arbitrary HTTP sites with requests." => de spec heeft dus 'maar' 3 doelen: NIET om autorisatieafspraken tussen partijen te maken. Daar houdt CE zich bewust verre van.
Wat niet wil zeggen dat je daar als gebruiker niet voor mag kiezen overigens. Maar dan ga je dus wel een stap verder dan wat de CE-spec hierover zegt.

[sjaakd]

Guidelines for NL-GOV profile CloudEvents, paragraaf 3.1.2

De paragraaf stelt nu:

---

The delivery request MUST use one of the following two methods (both of which lean on the OAuth 2.0 Bearer Token RFC6750 model):

• The access token is sent in the Authorization request header field; for OAuth 2.0 Bearer tokens, the "Bearer" scheme MUST be used.
• The access token is added to the HTTP Request URI Query component as described in URI Query Parameter.

---

Dit zou kunnen worden gewijzigd in:

Autorization can be, but is not limited to:

• No authorization e.g. for public notification services. Note that dimensioning becomes relevant.
• IP Whitelisting
• PKI client / PKI server infrastructure
• Java Web Tokens (JWT)
• OAuth2.
• ...

Note, in case of JWT or OAuth2, the delivery request SHOULD use one of the following two methods (both of which lean on the OAuth 2.0 Bearer Token RFC6750 model):

• The access token is sent in the Authorization request header field; for OAuth 2.0 Bearer tokens, the "Bearer" scheme MUST be used.
• The access token is added to the HTTP Request URI Query component as described in URI Query Parameter.

---

Welnu, ik heb geen ervaring met specificatie taal, maar ik denk dat het verplichte karaketer van oAuth2 moet worden weggelaten. Ik weet niet of we de geboden opties moeten beperken tot de pas-toe-of-leguit lijst. In dat geval moeten JWT en IP Whitelisting wellicht weer weg.