getWithRedirect clientId parameter not stored in the session cookie

[Daniel-Houston]

I am using the getWithRedirect() method to authenticate with okta. One of the parameters I am passing into the method is the clientId:

authClient.getWithRedirect({
    clientId: <clientId>,
    ...
}).then(...)

While doing this I noticed that the clientId is not stored in the session cookie, which means it will not be available for use in the parseFromUrl() function after the redirect, resulting in a token claim validation error. I have created a pull request which resolves this issue.

[Daniel-Houston]

Anyone able to merge this PR? Or if not why hasn't it been merged? I'd like to get this code in.

[jmelberg-okta]

Hey @Daniel-Houston - not sure I'm quite following why you'd need to pass this through the getWithRedirect method, when the clientID is already bound to the okta-auth-js object.

Regarding token validation - best practice is to assert against a known set of claims (issuer, aud, etc.) that are configured ahead of time, so you wouldn't need to be dependent on a cookie.

Are you using the token.verify method immediately after parsing tokens from the URL?

It might be helpful if you could give a little bit more information about your flow.

Thanks!

[Daniel-Houston]

Hey @jmelberg-okta, thanks for the reply!

My flow is a little bit wonky, and I think that's what led me to find this problem. I have created a UI 'shell' that loads different single-page apps depending on your url path base. e.g. If I have app1 and app2, and my url is www.example.com, when I navigate to www.example.com, the shell loads and takes me to www.example.com/app1. Then, when I click a top-level menu button it routes me to www.example.com/app2 and loads a different SPA. I know this is a little weird given the notion of a 'Single-Page-App' but our website has some special needs.

That being said, I configured both app1 and app2 in Okta as separate applications, and instead of passing in the clientID in the AuthClient constructor, I'm passing in the clientID for my different apps in the getWithRedirect() method, in order to allow me to use one AuthClient for multiple client applications. When I do that, I get an error: 'The jwt, iss, and aud arguments are all required' which I traced to lib/oauthUtil.js#validateClaims line 106.

function validateClaims(sdk, claims, aud, iss, nonce) {
  if (!claims || !iss || !aud) {
    throw new AuthSdkError('The jwt, iss, and aud arguments are all required');
  }
  ...

That clued me in to find that the clientID is being passed to that function from lib/token.js#verifyToken as the audience parameter.

oauthUtil.validateClaims(sdk, jwt.payload, token.clientId, token.issuer, nonce);

By following the chain up (verifyToken -> handleOAuthResponse -> parseFromUrl), I found that if the clientID isn't given as part of the AuthClient configuration, then it will be undefined when assigned in handleOAuthResponse,

function handleOAuthResponse(sdk, oauthParams, res, urls) {
  urls = urls || {};

  var tokenTypes = oauthParams.responseType;
  var scopes = util.clone(oauthParams.scopes);

  // ClientId is not in oauthParams (parsed from cookie) nor the sdk.options
  var clientId = oauthParams.clientId || sdk.options.clientId;

eventually causing the error in validateClaims (referenced above). My solution for this was to include the clientID in the cookie to account for the case that it was passed in as a parameter to one of the get methods (getWithRedirect, etc).

If you don't like this approach, I would recommend changing your documentation to say that clientID is required as part of the client configuration here.

Does that make more sense?

[jmelberg-okta]

Thanks @Daniel-Houston! That helps provide a bit more context in why you're seeing this issue. It seems like we're expecting oauthParams.clientId to exist in the cookie (via this method).

I'll try and get to #103 this week or next!

[jmelberg-okta]

Resolved with 2.0.0.