In Part 1, we kicked off with a high-level look at why SAML, often thought to be yesterday’s protocol, is still alive and well in today’s identity frontier. We talked through the good (SAML’s maturity and trustworthiness), the bad (market inertia, technical debt, and resource constraints), and tried to make sense of why many SaaS providers in 2025 still treat OIDC like it’s the new kid in town.

Now it’s time to talk about the ugly-what happens when you’re caught in the middle of a B2B integration or even planning for one, with an OIDC-only identity provider on one side and a SAML-only SaaS service provider on the other, and no native capability to bridge the two in sight? You can either find a different IdP, find a different SaaS provider, or you’re left building a solution yourself.

Let me be very clear: you should never roll your own authentication solution if you can avoid it. In my world that has been the mantra for the past decade if not longer and it’s even more applicable today than ever. There are security risks, maintenance headaches, operational burdens, and it often violates the simple “don’t reinvent the wheel" principle. But in those rare edge-case scenarios where the business demands it, the risk is manageable, and a commercial solution isn’t an option — there is a way forward, albeit an ugly one. It’s also important to take an overall risk-based approach. If this challenge happens to represent a small, non-material, percentage of your line of business- then why not build something?

In this post, I’ll walk you through a serverless SAML gateway built on AWS, acting as the translator and traffic cop between your OIDC IdP and a SAML SP. I’m simply calling this a “SAML Gateway”. It’s not the prettiest and not ideal. But, it’s secure, simple, it scales, and most importantly- it gets the job done!

For starters, I want to scope this to ensure I don’t end up with a post that takes 40 mins to read. Everything I’m going to talk through will use AWS serverless services- including Amazon Cognito as the core IdP. If you’re experimenting with this, I would recommend using the RSA SAML Test Service provider to test things out. Kudos to RSA for still having this site up and running, I’ve been using it for years! I will only focus on SP-initiated login flows, although what I’ll talk through can easily be fitted to support IdP-initiated, if needed. I will also not touch on encrypted SAML responses- this can also be fitted into the solution as well, if needed. Lastly, I don’t want to get into session management. One of the key differences between SAML and OIDC is session management vs token based authentication and authorization. The solution presented below does create a session in the backend during the auth flow, but I’m not returning any kind of session-cookie, from a SAML perspective. I also an not exposing any kind of session validity endpoint. By the way, there is no standardized session endpoint defined in SAML, although many modern SAML IdPs implement their own version of this. So if this is something needed, the solution can easily be retrofitted to accommodate this. On to the solution!

Reference Architecture

In addition to Amazon Cognito being the underlying IdP, there’s some other services that play important parts in this solution, this is depicted in the following reference architecture (figure 1).

Figure 1: SAML Gateway reference architecture

  • Amazon API Gateway (APIGW): Serves as the primary ingress and egress point with the service provider. This includes a SSO endpoint (inbound AuthnRequest, outbound SAMLResponse), a metadata endpoint, and a logout endpoint.
  • AWS Lambda: Lambda is doing all of the heavy lifting and orchestration. For simplicity, I would start with a single Lambda that handles all actions. Depending on the requirements and usage patterns, each endpoint could have its own dedicated Lambda. But between APIGW and Lambda, scaling here should not be an issue.
  • Amazon Cognito: The underlying identities will live in a Cognito user pool and/or will be federated through it. This really speaks to the versatility of Cognito being used in this solution. You don’t have to worry about building any federation components in this solution- all of that is offloaded to Cognito.
  • Amazon DynamoDB (DDB): There will be two different tables used in this solution. One is entirely for session management and the other is for your service provider settings. If by chance this solution is only used for a single service provider that just happens to only can be configured with a SAML IdP, you could consider hardcoding the service provider configuration into the Lambda function using environment variables.
  • AWS Key Management Service (KMS): Because we need to issue a SAMLResponse, we need to sign this. KMS will be used to sign our response and the public cert will be obtained from here to feed the metadata endpoint.

Sequence Flow

Now that you understand what AWS services would be used, how would all of this work? The unified sequence diagram is a bit large, so I’ve broken it down into three parts.

  • Part 1 (figure 2 below): The SAML AuthnRequest to the SSO endpoint. This handles the initial request from the service provider and ultimately performs a lookup against the service provider configurations table. This is where the SAML session gets created on the backend and generates a new stateId value that ultimately gets included in the request to the Cognito user pool Managed Login.
  • Part 2 (figure 3 below): This part of the flow is where the authentication of the end user is handed off to the Cognito user pool. Again, whether the user is a local user or a federated user, Cognito will seamlessly handle this for you. This includes everything from the response back from the IdP (if applicable), to maintaining and returning the stateId value we generated earlier.
  • Part 3 (figure 4 below): At this point, all of the heavy lifting and critical components of the SAML auth flow have been completed. This part of the sequence flow is really just displaying the metadata endpoint for the SAML Gateway and the logout endpoint.

Part 1: SAML AuthnRequest

Figure 2: Part 1 of SAML Gateway flow; initial handling of the AuthnRequest

Part 2: User authentication with Cognito and the SAMLReponse

Figure 3: Part 2 of SAML Gateway flow; user authentication and SAMLResponse

Part 3: Metadata and logout endpoints

Figure 4: Part 3 of SAML Gateway flow; metadata and lougout endpoints

The above sequence flows are numbered and the flows have detailed labels, so hopefully everything makes sense and you can see how this problem can be solved with a several serverless services from AWS. Since unified large sequence diagram was broken down into 3, the autonumbering is restarted. You if you need to reference this flow with anyone, you can use the the part number plus the step number. For example: “Part 1, step 2” is when the AuthnRequest is made. Feel free to contact me to get the full sequence diagram (using Mermaid.js).

Conclusion

Bridging modern OIDC IdPs with legacy SAML service providers isn’t always clean—but it can be done securely and scalably with the right architecture. While not ideal, this serverless SAML Gateway provides a pragmatic way to satisfy business and technical constraints without abandoning modern identity standards. By leveraging managed services like Amazon Cognito, Lambda, and API Gateway, you avoid reinventing core auth logic while still offering SAML compatibility. If you’re facing a similar challenge, this pattern may offer just enough to meet your requirements without compromising on security or maintainability. SAML may not be the future, but for now, it’s still part of the present—and this solution helps you meet it there.