Expose the json serde

[NikolayMetchev]

We are using AWS Cognito and wish to expose the InitiateAuth operation.
The Kotlin AWS SDK already has serde for the request and the response but it isn't usable outside the context of the AWS Kotlin SDK internals.
This endpoint is supposed to be called by a backend which can compute a secret hash but the front end would invoke almost identical REST endpoint without the secret hash. Therefore it would be useful in the back end implementation to be able to use the aws.sdk.kotlin.services.cognitoidentityprovider.serde.InitiateAuthOperationSerializer to go to json and aws.sdk.kotlin.services.cognitoidentityprovider.serde.InitiateAuthOperationDeserializer to convert from json. Instead we have to do our own serialization instead. Any plans to make those publicly usable in some way?

[ianbotsf]

Hi @NikolayMetchev, great question! There are no current plans to make the internals of serialization public because we haven't had a clear need to do so up until now. Maybe this discussion will change that. 🙂

Can you tell me a bit more about the request/response you want to send from your front end? Specifically:

• You mentioned going to a different REST endpoint...is that a non-AWS endpoint like a proxy or something? Have you tried running the request through the AWS SDK but customizing the endpoint URL?
• Does the expected response from the endpoint match the canonical format of InitiateAuth responses?
• You also mentioned not needing a secret hash for this case but the client shouldn't enforce the presence of a secret hash in authParameters (i.e., it's just a Map<String, String>? as far as the SDK knows). Is something preventing you from creating/executing a request without a secret hash?

[NikolayMetchev]

Hello @ianbotsf The documentation on the secret hash is here:

The idea is that our front end (javascript) will not know what the cognito client secret is. That will be looked up on the back end by calling the DescribeUserPoolClient endpoint.

So we want to create a REST endpoint that looks identical to the InitiateAuth endpoint of Cognito but the back end will fill in the client secret. We will do this with API Gateway and a Lambda implemented in Kotlin.

So your point 1 is probably valid and will probably work but I don't know that we need to use the javascript SDK and it isn't why we need the serde of cognito exposed.

Point 2 - We intend to make the REST endpoint identical to Cognito so it should match and hence why having the Kotlin Serde exposed will make this so much easier.

Point 3 - The point is not that we need help on the front end (javascript) but that we need help on the back end Lambda implementation in Kotlin.

[ianbotsf]

Oh I see, I seem to have misunderstood where the Kotlin is in your architecture (i.e., the backend, not the frontend). To help correct my understanding, can you verify that this is the sequence you're expecting:

• JS frontend makes an InitiateAuth-like request to your REST endpoint containing everything except the client secret
• Kotlin Lambda function receives the request and deserializes it (possibly using Kotlin SDK serde code)
• Lambda function invokes InitiateAuth via the Kotlin SDK with the input parameters from the deserialized frontend request and the client secret
• Lambda function returns the JSON response (unmodified?) back to the frontend

Is this your expectation? If so, I'm not sure the SDK's serde code will help you much. We only have serializers for requests and deserializers for responses. We don't have deserializers for requests because clients don't (typically) need to deserialize a request—services do. For the same reason, we have no serializers for responses either.

If my understanding is still flawed, please let me know!

[NikolayMetchev]

Hi, your understanding is correct. I appreciate that you only have the "wrong way" serialization logic.. but all that code is generated and I am sure it should be quite easy to generate the reverse logic as well and expose it if you were so inclined.

Another question is why don't you just use kotlinx.serialization instead of custom serialization logic. Then we kill several birds with 1 stone. If all the models were tagged with @Serializable everybody can serialize/deserialize to their hearts content.

[ianbotsf]

You're correct that it would be relatively easy (nothing is ever "quite easy" I'm afraid 😅) to generate the reverse logic and thus to have deserializers for requests and serializers for responses. That would also increase the size of our JARs substantially, which we try to avoid unless it addresses a proportionally-substantial customer use case. What you're trying to do makes sense and I can see why you want it but it's pretty far outside of the standard, supported use cases for AWS SDKs.

Currently, our code generation is focused solely on client-side use cases (i.e., sending requests, receiving responses) but we do have a goal to provide server-side code generation in the future. When that happens, we'll definitely have a way to provide the "right way for servers" serialization logic (i.e., parsing requests, serializing responses).

That said, as you mentioned, much of the code is already there in terms of the models and data shapes—the missing piece is the serde components you need for this request. You could consider copying what you need from the SDK code and then writing (or adapting) your own serde to work with it. I realize that's not a turnkey solution but it's at least a workaround for your case for the time being.

As for kotlinx.serialization, that's another great question—one the SDK team spent a lot of time considering during the design phase. Where we landed is that kotlinx.serialization, while powerful and well-supported by JetBrains for JSON, would not provide the kinds of flexibility we wanted in terms of data shapes or non-JSON serialization formats. For instance, there's no first-party XML support and the CBOR support is still experimental and lacking some of the features used by AWS services. We could've written more code to work around some of these limitations but it felt like the library simply wasn't a good fit for our use case.

That said, providing some kind of add-on support for kotlinx.serialization/@Serializable for our shapes is something we've also considered, possibly as separate artifacts, a new codegen mode, etc. It may even be a requirement when we tackle non-AWS client generation.

So, to wrap it all up, we cannot commit to adding non-client serde support to the SDK at this time. Your short-term alternatives include:

• Reusing the model shapes from the SDK code and writing/adapting your own serde logic
• Using an off-the-shelf JSON writer/parser to mimic the format of the InitiateAuth request/response
• Using a wholly custom request/response format for your frontend↔Lambda use case, possibly with @Serializable to simplify serde
• Cloning/copying the codegen logic and adding support for service-side serde yourself

[NikolayMetchev]

Thank you for the detailed explanation. Just as an FYI we went with writing kotlinx.serialization custom serializers for the Kotlin AWS SDK objects.