Initial OIDC support#15417
Conversation
|
I don't see any scope taken in account for oidc, which means they wont be able to generate @RolesAllowed annotations, or in my dedicate case, won't be able to generate proper documentation... |
|
what about we merge #15407 and they you can submit a PR on top to add support for scope? |
|
Yes I can rebase after it has been merged. |
|
Just merged #15407. Please rebase this PR when you've time. |
Changes OIDC to OpenIdConnect Adds generated files
ahmednfwela
left a comment
There was a problem hiding this comment.
there were some OIDC shortcuts
the project wont' build. can you please take a look? |
| |BasicAuth|✓|OAS2,OAS3 | ||
| |ApiKey|✓|OAS2,OAS3 | ||
| |OpenIDConnect|✗|OAS3 | ||
| |OpenIDConnect|✓|OAS3 |
There was a problem hiding this comment.
do these generators really support OpenIDConnect as part of the PR?
There was a problem hiding this comment.
Nope, but the pr check list said : Commit all changed files..
I wanted to separate preparatory work from generators work, cut into small chuncks ;)
| public String type; | ||
| public String scheme; | ||
| public Boolean isBasic, isOAuth, isApiKey, isOpenId; | ||
| public Boolean isBasic, isOAuth, isApiKey, isOpenIdConnect; |
There was a problem hiding this comment.
Sorry I may not be very clear before.
I think using OpenID is fine to represent the security definition type.
There was a problem hiding this comment.
isn't OpenId different from OpenIdConnect ? @wing328
There was a problem hiding this comment.
also according to the spec, it's openIdConnect
There was a problem hiding this comment.
it's the same thing.
also according to the spec, it's openIdConnect
Yup, so isOAuth should be named isOAuth2 instead if we simply follow that (but it's not the case)
I want to avoid mustache tags with long name if possible. That's why I suggest isOpenID instead.
There was a problem hiding this comment.
that's why I simply want to keep the naming introduced in #15407
it looks straightforward to me.
what do you guys think?
I don't mind using OpenIdConnect at all if that's what you guys prefer.
There was a problem hiding this comment.
I mean I don't mind, but it might confuse people to have some places with OpenId and others with OpenIdConnect, considering they are 2 different specs.
but an argument can be made here is that OpenId is deprecated, and it defaults to OpenIdConnect anyway.
so both is fine by me
There was a problem hiding this comment.
So I corrected all my rebase errors and left isOpenID too ease mustache templates. Just tell me If I should use isOpenIdConnect instead.
|
looks good. I'll fix https://github.com/OpenAPITools/openapi-generator/actions/runs/4934037685/jobs/8819091825?pr=15417 after merging this PR. |
Adds initial support for OpenID Connect security.
See #425
PR checklist
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.For Windows users, please run the script in Git BASH.
master(6.3.0) (minor release - breaking changes with fallbacks),7.0.x(breaking changes without fallbacks)