CODEWITHSUNDEEP
samlsaml-2.0oktaokta-api
Smolda
Smolda

Reputation: 902

SAML 2.0 response verification

Integrating one of my application with with SAML 2.0 single sign on. Using Okta provider for this. I came to the point where I receive base64 encoded "SAML response token" after successful authetication in okta and redirected back to my application. Within this token I see all the user details I need but here comes my question. Do I need to verify that response any futher or shall I just trust what I receice? Considering this token also contains signarure?

My idea for security would be to reach Okta again and verify if this was really issued by Okta. Not sure if this is even possible.

Using NodeJS for verification.

Upvotes: 0

Views: 1453

Answers (2)

Wiktor Zychla
Wiktor Zychla

Reputation: 48314

If by SAML response token you mean the samlp:Response issued according to the Web Browser Passsive SSO profile then then response contains an assertion and the assertion is signed by the Identity Provider (additionally, the whole response can also be signed).

There's a critical security requirement to always validate the response signature. This is mentioned in the SAML specs, section 4.1.4.3

The reason for this is as follows: in the Web Browser SSO Profile the token is returned by the Identity Provider in a web page that contains a simple form with SAMLResponse and RelayState fields and a bit of code that just autoPOSTs this form to your app. Technically, this means that for a short time the token is controlled by the user's web browser and this is where the token can be altered (or forged).

Thus, the protocol security heavily relies on the token's integrity which is achieved with the crypto signature - it's just a plain old XMLDSig signature applied to the SAML.

Your goal, as a token receiver is not only to validate the signature but also check the signature's certificate and compare it to the certificate you expect from the trusted provider (or a list of certificates of trusted providers).

Skipping this step makes your application vulnerable:

  • skipping the verification means users can alter the token (add/create/delete) claims to the assertion, the signature verification would fail but you skip it

  • skipping certificate matching against known certificate means users can forge their own assertions, sign it using a dummy certificate and present to your application. The signature verification step would succeed but you won't be aware that a dummy certificate was used to sign the assertion

Upvotes: 2

Andrew K.
Andrew K.

Reputation: 3351

If you don't want to do the proper token validation on a backend (don't blame you, it's a pain), then switch to OIDC. That's a better fit for authentication and authorization for the frontend.

If, however, the SAML response is sent to and handled by a backend, and some other token is being forwarded to your application, then you should evaluate what the requirement for the validation of that token is.

What isn't clear in your question is where in the user flow we're talking about, hence the number of comments on my answer.

Upvotes: 1

Related Questions