Accept explicit token endpoint on /internal/auth/v1/request-access-token#4214
Conversation
When using mCSD for addressing, the OAuth token endpoint must be provided to the AT-Request instead of being resolved via a DID-Document. This commit adds a request param for this.
1 new issue
|
|
Coverage Impact ⬇️ Merging this pull request will decrease total coverage on Modified Files with Diff Coverage (2)
🤖 Increase coverage with AI coding...🚦 See full report on Qlty Cloud » 🛟 Help
|
| authorization_server_endpoint: | ||
| type: string | ||
| format: uri | ||
| description: | | ||
| Optional. OAuth token endpoint URL of the authorizer (RFC 8414 `token_endpoint`). | ||
| When provided, this URL is used directly as the JWT `aud` claim, bypassing the | ||
| compound-service lookup on the authorizer's DID document. `service` remains | ||
| required and is still used as the `purposeOfUse` JWT claim. Intended for | ||
| clients that discover the endpoint out-of-band (e.g. via FHIR mCSD). | ||
| example: https://as.example.nl/ura/12345678/token |
There was a problem hiding this comment.
this is ambiguous, especially when compared to our v2/IAM API;
- in v2/IAM we have a request field
authorization_server, which holds the Authorization Server URL (base URL, so to say), which is NOT the token endpoint. This new endpoint has a postfix_endpoint, so it's inconsistent - In this v1 API it's used as Token Endpoint, but it sounds like it's the Authorization Server URL
I suggest to rename it to token_endpoint (or authorizer_token_endpoint to stay in line with the rest of the API)
There was a problem hiding this comment.
Well, the problem was already there in the JwtGrantResponse. That field contains exactly this value (as far as I understand correctly). So instead of either renaming that field which would cause a breaking change, use a different name here, which would cause an inconsistency, I opted for fixing it in docs by explicitly explaining this is the RFC 8414 token_endpoint.
Since the authorization_server field in v2 is named differently, I don't see a hard clash.
2 participants
Summary
Adds an optional
authorization_server_endpointfield to/internal/auth/v1/jwt-grantand/internal/auth/v1/request-access-token. When provided, it is used directly as the JWTaudclaim, bypassing the compound-service lookup on the authorizer's DID document.serviceremains required and still drives thepurposeOfUseJWT claim — this only overrides endpoint resolution.CreateJwtGrantRequestandRequestAccessTokenRequestare refactored onto a sharedJwtGrantBaseRequestviaallOfso the new field lives in one place.authorization_server_endpointkept as-is (description clarified, despite the name, it's the RFC 8414token_endpoint).Why
Preparing for the FHIR mCSD transition. Clients already perform mCSD lookups for data-access endpoints, so letting them pass the OAuth token endpoint explicitly keeps nuts-node agnostic of the discovery mechanism.