Problem:
OIDC CreateApplication requests in both app/v2beta and application/v2
accept an ID field (id / application_id), but the OIDC creation path
dropped it, always generating a new app ID/client ID.
Changes:
Thread the request-provided ID into the OIDC domain request in both
handlers.
Update the OIDC command path to use the provided AppID when present
(fallback to generated ID when empty), mirroring API apps.
Add integration tests covering provided IDs for OIDC CreateApplication
on v2beta and v2.
Tests:
go test -count=1 -tags integration
./internal/api/grpc/app/v2beta/integration_test -run
TestCreateOIDCApplication_WithProvidedID
go test -count=1 -tags integration
./internal/api/grpc/application/v2/integration_test -run
TestCreateOIDCApplication_WithProvidedID
Co-Authored-By: [TheRobotCarlson](https://github.com/TheRobotCarlson)
Co-Authored-By: Warp [[email protected]](mailto:[email protected])
---------
Co-authored-by: Brian Carlson <[email protected]>
Co-authored-by: Warp <[email protected]>
---------
Shoutout: [TheRobotCarlson](https://github.com/TheRobotCarlson)
Shoutout: [ostempel](https://github.com/ostempel)
# Which Problems Are Solved
This PR *partially* addresses #9450 . Specifically, it implements the
resource based API for the apps. APIs for app keys ARE not part of this
PR.
# How the Problems Are Solved
- `CreateApplication`, `PatchApplication` (update) and
`RegenerateClientSecret` endpoints are now unique for all app types:
API, SAML and OIDC apps.
- All new endpoints have integration tests
- All new endpoints are using permission checks V2
# Additional Changes
- The `ListApplications` endpoint allows to do sorting (see protobuf for
details) and filtering by app type (see protobuf).
- SAML and OIDC update endpoint can now receive requests for partial
updates
# Additional Context
Partially addresses #9450