...
We lichten de verschillende schermcomponenten thans hieronder graag even toe:. Als u technische vragen heeft bij één van deze componenten - of algemene vragen bij de OAuth Client Credentials Grant - kan u desgewenst steeds de algemene documentatie van het Toegangsbeheer (ACM) raadplegen. Per component wordt in onderstaande bovendien gerefereerd aan het specifieke documentatie-luikje ("doc").
Gebruiksvriendelijke naam
...
Hier worden de coördinaten opgenomen van de organisatie die eigenaar is van deze API. Deze coördinaten worden aangevuld door het Toegangsbeheer-team (ACM-team); u kan deze voor uw API dus voor een goed begrip niet wijzigen.
Toegelaten authenticatiemethodes voor
...
de API (doc)
Dit zijn de authenticatiemethodes die uw API mag gebruiken bij de introspectie van access tokens bij het Toegangsbeheer (ACM). Meer informatie omtrent de authenticatie van uw API, kan u desgewenst terugvinden in de algemene documentatie van het Toegangsbeheer (ACM). U kan de toegelaten authenticatiemethodes voor uw API hier desgewenst wijzigen.
Publieke JWK
...
U kan de toegelaten authenticatiemethodes voor uw API hier desgewenst wijzigen.
JWKS endpoint (doc)
Indien u onder "Toegelaten authenticatiemethodes voor de API" (zie boven), "Publiek JWKS-endpoint" selecteerde, dient u hier de URL van het endpoint aan te vullen. Opgelet: deze URL dient aan een aantal voorwaarden te voldoen:
- De URL moet pubiek beschikbaar zijn en luisteren op HTTPS.
- Er moet vanzelfsprekend een geldig server certificaat aanwezig zijn en geïssued worden door een publieke Certificate Authority of VO DCBaaS.
- De URL moet luisteren op de standaard HTTPS-poort (443).
- De nodige caching headers zouden gezet moeten worden zodat afnemers weten hoe lang de JWK’s gecached mogen worden.
- De beschikbaarheid van dit JWKS endpoint is cruciaal voor de correcte werking van de authenticaties.
Publieke JWK (doc)
Indien u onder "Toegelaten authenticatiemethodes voor de API" (zie boven), "Publieke JWK" selecteerde, dient u hier de desbetreffende publieke sleutel (JWK) te documenteren. Opgelet: deze sleutel dient aan een aantal voorwaarden te voldoen:
- We verwachten hier een publieke sleutel uit een asymmetrisch keypaar (symmetrische keys bieden immers geen meerwaarde t.o.v. de client/secret die ook gebruikt kan worden).
- Gelieve er steeds op te letten dat enkel het publieke deel doorgestuurd wordt: als er een private key meegestuurd wordt, dan dient dit keypaar als gecompromitteerd beschouwd te worden.
- Als key-type (kty) kan er gekozen worden voor RSA (aanbevolen) of voor EC (Elliptic Curve).
- Als algoritme (alg) zijn er meerdere opties mogelijk, waaronder:
- RS256 RSASSA-PKCS1-v1_5 met SHA-256 (aanbevolen)
- RS384 RSASSA-PKCS1-v1_5 met SHA-384
- RS512 RSASSA-PKCS1-v1_5 met SHA-512
- P-256 and SHA-256 (voor EC)
- P-384 and SHA-384 (voor EC)
- P-521 and SHA-512 (voor EC)
- De key-grootte moet minimaal 2048 bytes zijn.
- Een key-grootte van 4096 bytes is aanbevolen.
- Meer info is terug te vinden in RFC7517.
Merk tenslotte ook op dat het algortime HS256 niet aanvaard wordt. Bij dit algoritme wordt namelijk symmetrische encryptie gebruikt en zou de public key als secret gebruikt worden.
Client/Secret (doc)
Indien u onder "Toegelaten authenticatiemethodes voor de API" (zie boven), "Client/Secret (minst veilige optie)" selecteerde, kan u hier uw client secret kopiëren - of eventueel wijzigen indien uw vorige client secret werd gecompromitteerd. Merk op dat uw client secret strikt confidentieel behandeld dient te worden en onder geen beding gedeeld mag worden met derden. Authenticatie middels client ID en client secret wordt steeds als de minst veilige authenticatiemethode beschouwd.