-
Notifications
You must be signed in to change notification settings - Fork 7
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
feat(core): add oidc auth code flow [release] #587
Conversation
31d9290
to
e44ed10
Compare
65ac887
to
d9af8e5
Compare
d9af8e5
to
224ebc5
Compare
c0776ae
to
15f3a28
Compare
Codecov Report
@@ Coverage Diff @@
## master #587 +/- ##
===========================================
- Coverage 98.69% 75.72% -22.97%
===========================================
Files 19 86 +67
Lines 764 3077 +2313
Branches 51 470 +419
===========================================
+ Hits 754 2330 +1576
- Misses 10 719 +709
- Partials 0 28 +28
|
15f3a28
to
b018853
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.
looks good. Have some change requests. and/or comments
@@ -589,7 +631,7 @@ export default class BaseCogniteClient { | |||
user = null; | |||
} | |||
|
|||
if (!user || !user.access_token) { | |||
if (!user || user.access_token) { |
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.
is this intentional leaving out the !
in front of user.access_token
? did it came from my branch 🙈
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.
so if we don't have a user or a user WITH access token .... I think this is wrong
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.
yea, looks like a typo to me, good catch
@@ -57,7 +57,7 @@ function App() { | |||
|
|||
useEffect(() => { | |||
const login = async (client) => { | |||
const result = await client.loginWithOAuth({ | |||
const result = await client.loginWithOAuth('ADFS_OAUTH', { |
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.
needs to be updated to send in flow object
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.
fixed
@@ -61,7 +61,7 @@ function App() { | |||
|
|||
useEffect(() => { | |||
const login = async (client) => { | |||
const result = await client.loginWithOAuth({ | |||
const result = await client.loginWithOAuth('AAD_OAUTH', { |
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.
needs to be updated to send in flow object
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.
fixed
* } | ||
* }); | ||
* | ||
* // or with client credentials |
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.
this is not a part of this PR but will be a part of my PR. possibly remove.
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.
done
|
||
export type AuthFlowType = |
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.
so glad we did this. 🙌 much more readable and only by using a basic union with common fields
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.
Agree — this approach looks great
const client = useMemo(() => new CogniteClient({ appId: 'sample-app-id' }), []); | ||
|
||
useEffect(() => { | ||
client.loginWithOAuth('OIDC_AUTHORIZATION_CODE_FLOW', { |
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.
needs to be updated to send in flow object
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.
fixed
I have been doing a lot of thinking on the flow manager approach in the code. So, we have a flow manager and a method inside the base client that handles the flow. So the logic is spread into two places, the flow manager and the This could be solved in the following manner: case 'OIDC_VENDOR_GENERIC_CLIENT_CREDENTIALS_FLOW': {
this.vendorGenericFlowManager = new OidcVendorGeneric(flow.options, this.setCluster, this.setBearerToken);
[authenticate, token] = await this.vendorGenericFlowManager.init();
break;
} where the |
067dcbe
to
711f6c1
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.
As I mentioned before, my biggest concern is about a breaking change in general.
We have working adfs/aad flow, and breaking the users just for a cleaner code's sake is not really a good excuse. I doubt we have resources to backport bugfixes/features anyway, so by releasing this we just make external developer's life harder.
I would keep the same method we had before, and just introduce an additional one.
Something like setLoginConfig(...)
which wouldn't support API keys/legacy OAuth.
As I remember that was what we agreed on earlier.
The main purpose of the PR is to add OIDC support for Aize/Auth0. The API change is not motivated by clean code, but less brittle code. this is error prone, and the more flows you add, the more error prone it will be. |
BREAKING CHANGE: stop silencing errors from aad
BREAKING CHANGE!: stop guessing which flow to use based on content of options.
711f6c1
to
9c63176
Compare
I completely agree, therefore I suggested adding a separate function to handle all these different flows (all of them except the legacy one)
|
That would still be a breaking change for AAD/ADFS, so I don't see that as an alternative to the objection against frequent major version updates. I think the current setup is a good fit for changing flows in the future, e.g adding client credentials will be a minor change. The way I see it, this PR will be breaking and is an improvement. I don't see why adding a new method instead of changing the API is better?
Q1 22 at the earliest, but that is optimistic. Or, it has been deprecated since Q1 21, but I don't think it will be shut down before the last customer has migrated. So who knows.
This is also not correct, you are doing more than just setting the config (checking old tokens, trying to silently refresh them if possible). So the semantics of the existing method is a better fit. |
BREAKING CHANGE: loginWithOAuth signature is changed