-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sso-auth: decouple setting provider with options validation #6
Comments
I've started working on this. |
Sounds great, what is the approach you are planning to take in refactoring and decoupling the logic? |
I think I'll probably start by flagging sections of code that I think will be affected and linking them here for discussion. |
In some cases providers will send only an ID token, not access/refresh tokens. The session state struct should be expanded to include an ID token, and we should be more cautious about assuming an access token will always be present. sso/internal/pkg/sessions/session_state.go Lines 19 to 31 in a946076
Not having one probably shouldn't be an error if you have an ID token instead. In addition, as mentioned in #27, not all providers validate via an HTTP endpoint. Some providers use OIDC well-known locations to distribute keys which allows tokens to be validated without making extra round-trips. I'd probably recommend renaming this function as the method tokens are validated by is potentially provider-specific. I think there's going to be two fairly common validation strategies (HTTP validation endpoint & JWT w/ well-known key location). sso/internal/auth/authenticator.go Lines 827 to 856 in a946076
Since providers already have a validate method that takes a session state, once it's been expanded to include ID tokens, it should be easy enough for providers with no sso/internal/auth/providers/providers.go Lines 27 to 38 in a946076
The options stuff for Google I ran into immediately when I started on #27. Lines 203 to 210 in a946076
But this probably needs addressing: Lines 243 to 253 in a946076
The solution from https://github.com/bitly/oauth2_proxy strikes me as probably not difficult to port over (and indeed, having already taken a quick crack at it, so far that seems to be the case). I think the |
Potentially I think this could be two refactor PRs, one for options cleanup, one for validation & ID token prep work. |
What
Move out initializing providers from validating Options into to a separate function that can be taken in as an option function.
Why
Currently we set the provider as the google provider during validation of the
Options
struct which makes it difficult to add a new provider and to add new features to existing providers. Decoupling the logic from validating Options will make it simpler to support adding new providers.The text was updated successfully, but these errors were encountered: