djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add recommendations to dynamic client proposal

Browse Source
This commit is contained in:
Ryan Richard 2022-04-29 12:48:03 -07:00 committed by GitHub
parent 19149ff043
commit 56c8b9f884
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
proposals/1125_dynamic-supervisor-oidc-clients/README.md
View File

@ -478,6 +478,9 @@ desired.
## Open Questions ## Open Questions
- Which of the options presented above should we choose? Are there other options to consider? - Which of the options presented above should we choose? Are there other options to consider?
- The author of this propsal doc would like to recommend that we choose:
- "Option 1: Providing client secrets already hashed", because of the tradeoffs of advantages and disadvantages discussed above. And also because client secrets should be decided by admins (see paragraph about that above).
- And "Option 1: Explicitly associate specific clients with issuers", because it sets us up nicely for the upcoming multiple IDP feature. However, if the team does not have an appitite for doing this now, then we could choose "Option 2: Implicitly associate all clients with all issuers" for now and then reconsider when we implement the upcoming multiple IDPs feature. The security concerns raised above with Option 2 are especially important with multiple IDP support.
- Should we make the initial ID token from an authorization flow more inert? (See the audience confusion section above - Should we make the initial ID token from an authorization flow more inert? (See the audience confusion section above
for more details.) for more details.)