Oidc-client-js: Problem with AWS Cognito and the response_type

[avakkuri]

I would like to use this library as the client for our AWS Cognito instance. The configuration works fine with the Cognito except from the fact that Cognito accepts the response_type being only "code" or "token", which causes an issue. If the response type is "token id_token" it results an invalid request error from Cognito. Cognito returns the Id token just with the plain "token" response type if openid is defined in the scope.

How the logic currently works with oidc-client-js is that the response type needs to be "token id_token", so that isOidc in SigninRequest adds nonce to the request. Now the current behavior catches this when the callback is done at !state.nonce && response.id_token in the ResponseValidator processSigninParams as it notices the presence of the id token, but no nonce.

If there would be a way to force the nonce generation or then isOidc would additionally check openid from the scope the library would work out of the box with Cognito. Could one of these approaches be taken into use? It is true that this should be something that should need improvement in the Cognito side, however having this support in oidc-client-js side could bring flexibility to other integrations as well.

[brockallen]

This library mainly supports OIDC, thus the typical use of id_token token. code is only for use in server-side web apps (until the spec committees make other recommendations, but that's beyond this conversation). That leaves them only supporting token, which is not OIDC.

[kmontg]

Running into the same issue. Cognito returns both the access token and (OIDC) id_token with just the response_type of 'token' and doesn't support passing both 'id_token' and 'token' as a response_type. Are there any known workarounds so that the user profile is still loaded?

[michaeltecourt]

Unfortunately AWS is not even pretending to be complying with OIDC. In the "meantime" (if Amazon ever aligns Cognito with OIDC), I'll be extracting the username from the Access Token JWT.

[michaeltecourt]

@kmontg Late to the party but found a workaround.

If you request the scope openid, cognito will return an id_token that the oidc-client cannot validate since it didn't generate any nonce (we didn't ask for an id_token the right way after all).

The library is pretty well designed, so you can replace the ResponseValidator implementation through the oidcSettings :

class DummyResponseValidator {

    constructor(settings) {

    }

    /**
      * Please implement the actual validation without the nonce
      */
    validateSigninResponse(state, response) {
        console.log('Dummy Response Validator not doing anything...')
        return response;
    }
}


export const oidcSettings = {
    authority: "https://...",
   // ...
   ResponseValidatorCtor: DummyResponseValidator

[hauntingEcho]

gravedigging a bit, but I've found it easiest to work around this by constructing my UserManager and overrriding:

• ._validator._processSigninParams
• ._validator._validateIdTokenAttributes
• ._validator._validateIdToken

because the internals needed to make an effective validator implementation (dropping the couple of checks that AWS fails but keeping the rest) aren't all exposed at this point.

[sefo]

@michaeltecourt I couldn't make the custom validator work. Do you have a more complete example of what I should put in there?

@hauntingEcho Did you copy the class UserManager from the library and just changed the 3 attributes above? How did you call your new class in the callback.html file? var mgr = new Oidc.UserManager({userStore: new Oidc.WebStorageStateStore()}); (couldn't find those values in the class UserManager)

[michaeltecourt]

Sorry, I forgot to update my answer. After struggling for hours, I gave up on implementing a clean validator and ended up with an uggly patch in my OIDC Callback handler : I just renamed the id_token so the validator does not take it into account.

    // FIXME Huge hack to circumvent the fact that Amazon does not implement OIDC properly
    let url = window.location.href.replace('id_token', 'not_an_id_token')
    this.oidcSignInCallback(url)

[sefo]

That did the trick, thanks a lot for answering so quick! I didn't know I could pass the url to that function...

Now I'm facing a CORS issue on "xxx/oauth2/.well-known/openid-configuration" but that's surely configurable somewhere...