[WIP] Add OpenID Connect login - #2585
Draft
daimond113 wants to merge 1 commit into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Adds an OpenID Connect login type, which is useful particularly for setups that rely on SSO. Discussions around this have been made in #189 and #1620.
Short description
Currently, this is an OpenID Connect only login method - no support for raw OAuth2. If wanted, adding individual fields for the required URLs (as mentioned here) is a possible alternative.
Using this login type requires a client id of a public client. Capturing cookies has been proposed as an alternative here, but it isn't OAuth/OIDC-compliant so it is generally better to avoid it.
Dynamic client registration could also be utilised, but it is rather rare for IdPs to support it which reduces its viability as an alternative.
Open questions:
parseAuthorizationHeadersbut it is marked as an InternalApi. This can be solved by either opting in, or writing a mini parser ourselvessuggestedAccountNameisn't filled in because there isn't a JWT parser in any libraries. Should a dependency be added, or perhaps should we just handroll a parser for the payload?Checklist