Bakgrund
Inom Sweden Connect finns sedan tidigare OIDC Metadata Requirements, som kompletterar de underliggande standarderna genom att ange vilka metadata som ska eller bör publiceras för olika protokollentiteter.
På motsvarande sätt finns behov av att inom Samordnad identitet och behörighet tydliggöra vilka metadata som krävs för OAuth Client, Authorization Server och Resource Server, inklusive gemensam metadata och hantering av protokollnycklar.
Som utgångspunkt används Sweden Connect – OIDC Metadata Requirements: Sweden Connect – OIDC Metadata Requirements
1. Syfte
Denna specifikation anger krav på federationsmetadata för OAuth 2.0-protokollentiteter inom Samordnad identitet och behörighet.
...
Organisationsidentifieraren bör vara central eftersom federationsplattformens tekniska ramverk redan anger att denna metadata används för att koppla en teknisk komponent till ansvarig organisation.
Organisationsidentifieraren bör följa en gemensam standard:
- Struktur enligt GLobal Unique Enterprise Identifier (GLUE)
- https://datatracker.ietf.org/doc/draft-ietf-spice-glue-id/10/
- Denna ger möjlighet att stödja flera olika typer av identifierare samtidigt.
- ISO/IEC 6523
- internationell standard som definierar hur organisationer och delar av organisationer identifieras på ett entydigt sätt i elektronisk dataöverföring
- Rekommenderade format baserade på ovan standarder (vilka kan byggas ut efter behov):
- Svenskt organisationsnummer (ICD 0007)
- urn:glue:iso6523:0007:xxxxxxxxxx
- GLN-kod (ICD 0088)
- urn:glue:iso6523:0088:<gln-kod>
- Domänbaserad eDelivery Participant Identifier (ICD 0203)
- urn:glue:iso6523:0203:foretaget.se
- Svenskt organisationsnummer (ICD 0007)
3. Protokollnycklar
Om en protokollentitet använder asymmetriska nycklar i OAuth-protokollet ska dess publika protokollnycklar kunna hämtas från metadata.
...
Dessa nycklar är separata från de federationsnycklar som används för att signera Entity Statements.Förslag: en entitet som behöver publicera protokollnycklar ska publicera dessa genom en av de mekanismer som tillåts av den tekniska profilen. Vi bör alltså inte göra jwks specifikt REQUIRED om exempelvis signed_jwks_uri ska vara det föredragna alternativet.-
4. OAuth Client
Entity type: oauth_client.
...
Entity type: oauth_authorization_server.
OIDF anger att metadata enligt RFC 8414 och relevanta registrerade metadatafält får användas. issuer har dessutom ett uttryckligt OIDF-krav: värdet ska motsvara entitetens Federation Entity Identifier.
Föreslagna krav:
| Metadata | Krav | Kommentar |
|---|---|---|
| Gemensamma metadata enligt avsnitt 2 | REQUIRED enligt ovan | |
issuer | REQUIRED | Ska motsvara Federation Entity Identifier. |
token_endpoint | REQUIRED | Endpoint för utfärdande av access tokens. |
grant_types_supported | REQUIRED | Grant types som AS stöder. |
token_endpoint_auth_methods_supported | REQUIRED | Tillåtna autentiseringsmetoder för klienter. |
token_endpoint_auth_signing_alg_values_supported | CONDITIONAL | Ska anges om signerad klientautentisering används. |
scopes_supported | RECOMMENDED | Scope som AS kan utfärda. |
jwks, jwks_uri eller signed_jwks_uri | REQUIRED när publika protokollnycklar behövs | Exempelvis för verifiering av signerade JWT. |
...
Entity type: oauth_resource.OIDF anger att gemensamma metadata kan användas och att en deployment dessutom får använda Protected Resource Metadata enligt RFC 9728.
Föreslagna krav:
| Metadata | Krav | Kommentar |
|---|---|---|
| Gemensamma metadata enligt avsnitt 2 | REQUIRED enligt ovan | |
resource | REQUIRED | Identifierar den skyddade resursen. |
authorization_servers | RECOMMENDED | Anger vilka Authorization Servers som kan användas för resursen. |
scopes_supported | RECOMMENDED | Anger vilka OAuth scopes resursen känner till. |
bearer_methods_supported | OPTIONAL | Om relevant för vald interoperabilitetsprofil. |
jwks, jwks_uri eller signed_jwks_uri | CONDITIONAL | Krävs endast om Resource Server har protokollnycklar som andra parter behöver verifiera. |
Här skulle jag vara mer försiktig än för Client och AS. Exakt vilka RFC 9728-fält som ska vara REQUIRED bör avgöras tillsammans med användningsfallen och Ena OAuth-profilen, eftersom OIDF själv endast anger att dessa metadata får användas.
7. Metadata policy
De krav som lämpar sig för maskinell kontroll bör kunna uttryckas genom OpenID Federations metadata_policy.
...
- att obligatoriska metadata finns
- tillåtna
grant_types - tillåtna klientautentiseringsmetoder
- tillåtna algoritmer
...