-
Notifications
You must be signed in to change notification settings - Fork 1
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
🔥 Remove 'keycloak realm' as param #68
🔥 Remove 'keycloak realm' as param #68
Conversation
Yeah I did this but was never terribly happy with it. All OIDC providers/IdPs (Okta, etc) that are multitenant (that is, all of them) will have a similar construct (org, realm, etc) - but yeah I see no real reason why we can't just make it part of the URL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
64fdacc
64fdacc
to
f1c3890
Compare
79087b3
to
4090cb4
Compare
3c9fb49
to
16dd0dc
Compare
- Previously, we explicitly required passing in 'realm', variously referred to as `orgName` or `organizationName`, which we then used to build a keycloak-style URL - This is not part of the OIDC spec and a keycloak addition to support multi-tenancy. This is evident in how all realm requests are based off the `[root]/realms[realm]` path, including the `.well-known` OIDC discovery paths. - Instead, explicitly include the path as part of the root OIDC url - While I'm here, remove a few explicit references to keycloak
16dd0dc
to
50fdd58
Compare
This gets rid of the 'unsupported version of typescript' error, as this version supports ts 4.8
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
orgName
ororganizationName
, which we then used to build a keycloak-style URL[root]/realms[realm]
path, including the.well-known
OIDC discovery paths.