Add jwt bearer for user authentication#1232
Add jwt bearer for user authentication#1232jochenehret merged 2 commits intocloudfoundry:developfrom
Conversation
…or a while A default CF should have it, because of cloudfoundry/cli#3368 Another reason to allow alternative to password grant https://datatracker.ietf.org/doc/html/rfc9700#section-2.4
|
@jochenehret FYI, this PR is more useful if cloudfoundry/cli#3397 is accepted, because then the normal USER in cf can run it, but even without cf - client adoption the REST calls to UAA can be done |
|
Ok. Are there any possible side-effects we should be aware of? |
Only this change has no effect (include side effect), but this change can improve situation if we have at least the enhancements in cf client. I am not sure if we need a RFC from CF TOC side to announce it. The bigger change or breaking change will be if we finally remove password as authorized-grant-types from cf client. So I see it similar to move from v2 to v3. This change here simply adds v3 and therefore no side effect now. |
2 participants
Please take a moment to review the questions before submitting the PR
WHAT is this change about?
Add JWT bearer to the defaults of allowed grant type.
JWT bearer should replace password grants, but we need to have both for a while
A default CF should have it, because of
cloudfoundry/cli#3368
Another reason to allow alternative to password grant https://datatracker.ietf.org/doc/html/rfc9700#section-2.4
What customer problem is being addressed? Use customer persona to define the problem e.g. Alana is unable to...
No problem, but enhancement. Customer should not use their password, but tokens, therefore support jwt bearer to support customer needs.
Problem can be that agency and rules enforce us ( CF ) to omit password, see https://datatracker.ietf.org/doc/html/rfc9700#section-2.4 -> password grant MUST NOT BE USED ....
Please provide any contextual information.
Describe the actions in this issue
UAA issue
cloudfoundry/uaa#3285
CF CLI issue
cloudfoundry/cli#3368
RFC
https://datatracker.ietf.org/doc/html/rfc9700#section-2.4
Has a cf-deployment including this change passed cf-acceptance-tests?
Does this PR introduce a breaking change? Please take a moment to read through the examples before answering the question.
How should this change be described in cf-deployment release notes?
Yes please, annonce it as new possibility, if cloudfoundry/cli#3368 is merged.
Does this PR introduce a new BOSH release into the base cf-deployment.yml manifest or any ops-files?
Does this PR make a change to an experimental or GA'd feature/component?
Please provide Acceptance Criteria for this change?
JWT bearer with cf client works,
What is the level of urgency for publishing this change?
Tag your pair, your PM, and/or team!
UAA Team