Skip to content
This repository has been archived by the owner on Jul 26, 2022. It is now read-only.

feat(jwt-verifier): Removes check of client_id from access tokens #477

Merged
merged 2 commits into from
Jun 17, 2019

Conversation

swiftone
Copy link
Contributor

PR Checklist

Please check if your PR fulfills the following requirements:

  • The commit message follows our guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Adding Tests
  • Build related changes
  • CI related changes
  • Documentation changes
  • Other... Please describe:

What is the current behavior?

clientId/client_id was required, even for access tokens that, per spec, do not require client id

Issue Number: #367

What is the new behavior?

clientId is now optional, and will only be asserted if such an assertion is requested via customClaims

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

Reviewers

@aarongranick-okta

Copy link
Contributor

@robertjd robertjd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few questions

@@ -95,22 +94,14 @@ describe('jwt-verifier configuration validation', () => {
expect(createInstance).toThrow();
});

it('should throw if the client_id is not provided', () => {
it('should NOT throw if client_id not matching {clientId} is provided', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this testing? That we don't throw if they provide a client_id?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asserting that the input is allowed, and is NOT checked against the claims automatically.

That's not exciting, but this documents the expected behavior for this case.

@@ -63,9 +63,10 @@ class OktaJwtVerifier {
constructor(options = {}) {
// Assert configuration
assertIssuer(options.issuer, options.testing);
assertClientId(options.clientId);
if( options.clientId ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we even need assertClientId anymore? Or should we just let this be handled by the custom claims assertion logic?

Copy link
Contributor Author

@swiftone swiftone Jun 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The value here is catching "{clientId}" cases.

assertClientId doesn't validate the claim, it checks for a well-formed and present clientId.

@swiftone swiftone merged commit 2f2d39f into master Jun 17, 2019
@swiftone swiftone deleted the br-hat-jwt-client-id-OKTA-227986 branch June 17, 2019 22:57
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants