Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Custom bearer token interceptor could pick wrong condition #618

Open
Tlepel opened this issue Jan 28, 2025 · 4 comments · May be fixed by #619
Open

Custom bearer token interceptor could pick wrong condition #618

Tlepel opened this issue Jan 28, 2025 · 4 comments · May be fixed by #619

Comments

@Tlepel
Copy link

Tlepel commented Jan 28, 2025 •
edited
Loading

The implementation of the custom bearer token interceptor has a flaw: take the following example:

const myConditions = [
  { shouldAddToken: () => false, id: 0 },
  { shouldAddToken: () => Promise.resolve(false), id: 1, },
  {
    shouldAddToken: async () =>
      new Promise((resolve) => {
        setTimeout(() => resolve(false), 200);
      }),
    id: 2,
  },
  {
    shouldAddToken: () => true,
    id: 3,
  }
];

/* This line was copied from the custom bearer token interceptor implementation */
const matchingCondition = myConditions.find(async (condition) => await condition.shouldAddToken());
console.log(matchingCondition.id); // Should print 3, but it prints 0

This should return the last condition, but it doesn't. That would be problematic if the bearerPrefix or authorizationHeaderName would be set to non-default values for condition 2 and/or 3, since the config for condition 2 would be used for requests matching condition 3.
@Tlepel
Copy link
Author

Tlepel commented Jan 28, 2025

The cause is that Array.prototype.find doesn't actually evaluate async functions fully. The async function returns a Promise, which is truthy, so the first condition is always returned (and always matches), even if the condition is a synchronous function that returns false.

Tlepel added a commit to RiskChallenger/keycloak-angular that referenced this issue Jan 28, 2025
@Tlepel
fix: evaluate async conditions in the custom bearer token interceptor
fa5a2dc 
fix mauriciovigolo#618
@Tlepel Tlepel linked a pull request Jan 28, 2025 that will close this issue
Open
3 tasks
@Tlepel
Copy link
Author

Tlepel commented Jan 28, 2025

This might be a sensitive issue security wise, since this implementation might cause bearer tokens to be sent to 3rd party receivers, essentially unintentionally 'sharing' the token with services that shouldn't have that token.

@Tlepel
Copy link
Author

Tlepel commented Jan 28, 2025

I've added a (failing) test case to the custom-bearer-token.interceptor.spec.ts file in my PR #619

@lucas-pollus
Copy link

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@Tlepel @lucas-pollus