-
Notifications
You must be signed in to change notification settings - Fork 4
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
OAuth migration | Core OAuth authentication middleware #1223
Conversation
e042e6d
to
f231bda
Compare
f231bda
to
1df44cc
Compare
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.
looking good so far from my side, a few changes required though i think
We do not need to generate IDAPI cookies by making a separate call to IDAPI as part of the OAuth flow because Gateway already generates these for us. However, in DEV, we have been pointing MMA to CODE Gateway during the OAuth flow, which means that the cookies have been inaccessible from DEV MMA. Changes: - Remove the code to generate IDAPI cookies - Point MMA DEV to Gateway DEV for OAuth - Create a dev OpenID client which correctly sets and checks the access/ID tokens, which are set to validate against CODE Okta, despite running in DEV.
ad0be7b
to
90d7231
Compare
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.
amazing work!
Overdue on PROD (merged by @raphaelkabo 15 minutes and 6 seconds ago) What's gone wrong? |
Seen on PROD (merged by @raphaelkabo 1 hour, 16 minutes and 17 seconds ago) Please check your changes! |
This PR migrates the authentication middleware used by the MMA Express server from 'classic' (calling IDAPI's
/auth/redirect
endpoint on every request) to Okta-powered OAuth2.Warning
The new OAuth mechanism this PR introduces is disabled by setting
useOAuth: false
in theokta-STAGE.json
config file stored in S3. It should remain disabled until the upcoming 'server-side Okta auth' PR is merged in, because without that PR, if OAuth were enabled, we would be introducing a security vulnerability in accessing certain APIs. We want to merge this PR into main though, to prevent needing to keep it updated with main and to spot any hidden issues early in testing. While theuseOAuth
flag is set tofalse
, the authentication behaviour will be identical to how it has always worked.Changes
@okta/jwt-verifier
(to verify OAuth tokens),openid-client
(to set up an OIDC client in MMA), andms
(because counting is hard and that's why we have computers).withIdentity
authentication middleware now calls one of two functions:authenticateWithIdapi
, which is the old middleware, orauthenticateWithOAuth
, which is the new middleware. This is controlled by auseOkta
boolean in the Okta config file stored in S3 and retrieved byoktaConfig.ts
.useOAuth
. (This is okay because MMA sessions are only valid for 30 minutes anyway).useOAuth
is true, we're still dual-running this migration with the classic authorization behaviour for API endpoints handled by MMA. WhenuseOAuth
is true, users will authenticate via OAuth, but all API calls will still be authorized with the classic IDAPI cookies./oauth/callback
, the callback route to which the browser returns after the user gets a valid session.Huge thanks to @coldlink (I borrowed a lot of the OAuth code from his work in Gateway) and @pvighi, who both helped a lot with bringing this PR together.
SC_GU_U
,SC_GU_LA
,GU_U
GU_ACCESS_TOKEN
,GU_ID_TOKEN
,GU_SO
,SC_GU_U
,SC_GU_LA
,GU_U
GU_ACCESS_TOKEN
,GU_ID_TOKEN
,GU_SO
,GU_U
withOAuth: false
: SC_GU_LA generated in the last 30 minuteswithOAuth: true
: OAuth tokens which have expiry of 30 minuteswithOAuth: false
: Calls IDAPI to validate cookieswithOAuth: true
: After local validation, calls Okta to validate tokens for API-token-based API routeswithOAuth: true
: Locally validates OAuth tokensA quick recap of the new authentication flow:
GU_SO
cookie, we need to log the user out. We delete the access and ID token cookies and redirect the user to Gateway for authorization./oauth/callback
. Here we exchange the token we receive for access and ID tokens from Okta, and call IDAPI to give us a fresh set of classic IDAPI cookies.Reviews and testing
It might be easiest to go through this PR commit-by-commit, which I've done my best to make easy to do. There are a couple of support commits, one large commit introduces the two parts of the OAuth middleware flow, and then a commit with a suite of Jest tests.
We'll test this by deploying it on CODE and running some manual tests, as noted in this testing plan. Then we'll do the same on PROD.
Remaining work
maxAge
parameter to force reauth (Handle maxAge parameter gateway#2444)clientId
when validating access and ID tokensRelated PRs