Hello! I'm new to the GoodData community slack, sorry if I skipped some protocol before writing on this channel. I write in behalf of Indigo Tech Group to kindly ask for help with the integration with GoodData. We're currently trying to use the Cognito user pool as an identity provider for GoodData by using user pool client that we use for login to authenticate with GoodData via

TigerJwtAuthProvider

. We've followed all the steps laid out in the documentation and the API is still giving us a 401 when passed a JWT in the Authorization Bearer header. These are the steps we've followed so far: - Added the user client ID and secret to GoodData - Stored the user pool JWKs in the GoodData JWK store - Provisioned a user in both the Cognito user pool and in GoodData - Authenticated the user using the same client ID and secret - Used the generated JWT in the GoodData API (

GET api/v1/layout/organization

for testing purposes) The result is still the same: 401 Unauthorized. I tested through the

TigerJwtAuthProvider

implementation and it didn’t work either. Is there a step (or steps) we're missing? Should this approach work? Thanks in advance.

Hi Daniel, Can you please confirm if you are just using the

name

user attribute, as it is only required? Check to make sure you have added the name attribute to a Cognito record. If you are still facing issues, could you please provide a related traceID from the console?

Here's an example of how we're setting the user, the id property contains the Cognito user name, is this field what you're referring to?

I'm referring to the name attribute used in creating the user pool: https://www.gooddata.com/docs/cloud/manage-organization/set-up-authentication/aws-cognito/#UseAmazonCognitoasIdentityProvider-CreateCognitouserpool

Oh I see, hmm I'll let you know if I can configure that part on the user pool, thanks

Hey Daniel, I’ve actually escalated this to our L2 technical support team and they are currently looking into it for you. They will follow up as soon as possible

Oh great, thank you 🙏

Watching this too (I work at same org)

Heya Michael, Daniel, sorry for the delay! Radek from L2 here, I've been checking into this and should have more later today 🙂

Hey @Radek Novacek any update on this? Thanks!

Hey Michael, this is really looking a lot like an issue with the JWK - could you double check that it looks okay? The error comes up as

The JWT contains invalid claims: [name].

, but under the hood, this is only following

Signed JWT rejected: Another algorithm expected, or no matching key(s) found

.

Hello Radek, just to make sure before I retest, I should use the access token and no the id token, right? Also, the JWKs I stored were the ones from the user pool that's being used, is that a correct approach? or should we create new ones?

We launch our product in 9 days and this impacts a feature we’re launching with

Heya Michael, Daniel, the access token is the correct one to use, yes 👍 I think same goes for the JWKs but I'm trying to double check so that I can confirm 100%!

Thanks for your continued help Radek!

Hi again, one thing that could be helpful here - could you share with me over DM both a JWT (just in case, both access and ID to be extra sure), and the JWKs from the

/api/v1/entities/jwks

endpoint so that we can go over these and verify everything is as it should be? Many thanks in advance! 🙂

Thanks Radek!!

Hi all, our engineers have gone over the examples and the logs - a correction for my part, the correct token to use is indeed the ID token. Checking into the code that actually handles the error, unfortunately the reported phrase says almost exactly the opposite of what it detects as well -

The JWT contains invalid claims: [name].

is trying to report the "name" claim is missing entirely (which makes it invalid).. I know you mentioned you tried the ID tokens before, however from the logs, I can only find

Token is not a valid Jwt

errors. Do you think you could try to test the setup with ID tokens? Worst case, we get another error to follow, and if I get the token used alongside it, we should know exactly where to go next!

Hello Radek, I'll be testing with the idToken today, I'll send you the results

Hi David, how's the testing looking? 🙂

Hey @Radek Novacek, we are just trying to get silent login set up in our app. When a user navigates to a page in our app that contains a GoodData dashboard, we don’t want them to enter credentials. Do you have docs for using the ID token? We were guided to use a JWT-based approach by GoodData professional services. But if there is an easier, equally secure route, that would be great.

Heya @Michael Gray, I'm assuming your overall setup is something like this: • you have a user pool that is the same in Cognito and GoodData • your parent app uses OIDC login via Cognito to authenticate users • since you already have the auth session context, including the ID/access tokens for each user, you're trying to use these in a JWT flow for GoodData auth If the above is correct, then it should also be possible to use the same auth context with the GD.UI SDK. The idea is that you'd set up a classic OIDC flow to GoodData and verify that you can log in to the non-embedded environment first; afterwards, on the app side, you would wrap your app in a React context provider with the auth info, a little like this:

ReactDOM.render(
  <React.StrictMode>
    <AuthProvider>
      <App />
    </AuthProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

(the implementation can differ based on your app structure, but this would provide the auth context to the whole app - I found a 3rd party article that describes a seemingly good way to do this for Cognito here) That way, when you embed the actual GD.UI Dashboard, you can use the GD-provided authentication provider from the documentation. On loading the component, the login flow will recognize that there is no session, attempt to authenticate with Cognito, identify the current session from the parent app, and then load the Dashboard. It's worth keeping in mind that this approach can result in a brief flash of a "no session" error from GoodData, we are currently investigating the login flow implementation and improvements are likely going to arrive soon, but for the time being, it's possible to work around this error by checking for the state of the backend - a simplified example is here:

const [isLoggedIn, setIsLoggedIn] = useState(false);

  useEffect(() => {
    backend.currentUser().getUser().then(() => setIsLoggedIn(true));
  }, []);

  return (
    <BackendProvider backend={backend}>
      <WorkspaceProvider workspace={workspaceId}>
        {isLoggedIn ? <Dashboard dashboard={dashboardId} /> : <div>{ a loading screen would go here }</div>}
      </WorkspaceProvider>
    </BackendProvider>
  );

The error mentioned above only shows up for the first load of the Dashboard in the session though, any subsequent switches to the tab should be seamless. Overall, since this relies on OIDC, it's as secure as any other OIDC flows are, and unless any unexpected issues arise, it's relatively straightforward as well! Please let me know your thoughts, I'd be happy to elaborate 🙂

Hey Radek thanks for this detailed info! I will make sure Daniel sees this and we’ll see what he decides to do 👍 Thanks for sticking with us on this issue for so long!

Hello Radek, sorry for the wait, our testing environment wasn't available, going back to what you asked about testing with the idToken generated at login, this is the result, the same as the last time I tested with the idToken

Hey @Radek Novacek We’ve also followed your suggestion above to use auth context with the GD.UI SDK, and the GD-provided authentication provider from the documentation. We’ve wrapped our app in an AuthProvider where we store our CognitoUserSession as the context provider value to be consumed by the whole app. Here is our setup:

export const ReportDashboard = () => {
  const authContextValues = useContext(AuthContext)
  console.log(authContextValues)

  const backend = tigerFactory()
    .onHostname(indigoGoodDataDomain)
    .withAuthentication(new ContextDeferredAuthProvider(redirectToTigerAuthentication))

  return (
    <BackendProvider backend={backend}>
      <WorkspaceProvider workspace={workspaceId}>
        <Dashboard dashboard={idRef(reportId)} />
      </WorkspaceProvider>
    </BackendProvider>
  )
}

The

authContextValues

is our stored CognitoUserSession and logs in this component as:

const authContextValues = {
  idToken: {
    jwtToken: '*****',
    payload: {
      sub: '*****',
      iss: '*****',
      'cognito:username': '*****',
      origin_jti: '*****',
      aud: '*****',
      event_id: '*****',
      token_use: 'id',
      auth_time: 1724806746,
      name: '*****',
      exp: 1724807646,
      iat: 1724806746,
      jti: '*****',
    },
  },
  refreshToken: {
    token: '*****',
  },
  accessToken: {
    jwtToken: '*****',
    payload: {
      sub: '*****',
      iss: '*****',
      client_id: '*****',
      origin_jti: '*****',
      event_id: '*****',
      token_use: 'access',
      scope: '*****',
      auth_time: 1724806746,
      exp: 1724807646,
      iat: 1724806746,
      jti: '*****',
      username: '*****',
    },
  },
  clockDrift: 0,
}

With this set up, the

ContextDeferredAuthProvider

still isn’t able to authenticate to Cognito and we are redirected to tiger authentication url every time. After we complete that login flow, we are redirected back to our app and are able to see the dashboard correctly. Are there any other steps we are missing? Or what is the ContextDeferredAuthProvider expecting to consume from our AuthProvider that we are missing?

Hi Michael, I will send David a part of a sample implementation for this - using Auth0 as an example, but should be helpful to setting this up. There are some important considerations to this, but I think it's best communicated via code 🙂 For the test done with the idToken, we are getting

InvalidBearerTokenException: Token is not a valid Jwt

- I'll double-check the contents internally!

Hey @Radek Novacek, regarding the non-JWT approach, we looked at your example code (thanks!) and see that it requires 3rd party cookies which are disabled by default in chrome and eventually gonna be phased out. For that reason we’re not sure if that method is gonna work. Regarding: “For the test done with the idToken, we are getting

InvalidBearerTokenException: Token is not a valid Jwt

- I’ll double-check the contents internally!” Daniel is wondering if there are any updates around that. Thanks!

Heya @Michael Gray, you're right about the 3rd party cookies, although this is fixed by using the same domain for the parent application and GoodData Cloud (mentioned here in the documentation, this is a general silent login issue, so not React-specific). On the JWT approach, I'm trying to check with the developer that worked on the JWT implementation for the Cloud - I will ask him if he'd be available to hop on a call with us at 4PM, although it might be a little last minute, so I'll keep you updated on that (and the ID token check) 🙂.