SAML logout response reports `urn:oasis:names:tc:SAML:2.0:status:AuthnFailed`, okta logs `Invalid Signature`, what was done wrong ?

Loading

Skip to Navigation Skip to Main Content

Search

Search

Select Language

0D54z0000A9mVCBCQ2Okta Classic EngineSingle Sign-OnAnswered2025-07-29T09:01:51.000Z2024-06-24T12:09:47.000Z2024-06-26T15:48:35.000Z

6bbqh (6bbqh) asked a question.

June 24, 2024 at 12:09 PM

SAML logout response reports `urn:oasis:names:tc:SAML:2.0:status:AuthnFailed`, okta logs `Invalid Signature`, what was done wrong ?

I have seen and read several related questions about these symptoms, and possible causes.

(My initial text exceeded your description size limit. Footnotes will be posted as comment to this)

So, to address these first, to hopefully convince the reader that whatever my problem is, it is not these.

* Mismatched certs ?

As far as I can tell with the tools given to me by the okta dashboard for the okta instance [1], the certs in okta and my logout request are the same. To wit:

The cert is locally stored in file `cert.pem`, with issuer and validity information of

```

Issuer: C = de, ST = nrw, L = willich, O = suse-rancher, OU = saml-test, CN = tagetarl

Validity

Not Before: Jun 24 10:52:04 2024 GMT

Not After : Jun 22 10:52:04 2034 GMT

```

Immediately after upload of the cert under the advanced SAML options of the config editor it shows

```

Uploaded by Alexandre Alves on Mon Jun 24 10:59:57 UTC 2024

CN=tagetarl,OU=saml-test,O=suse-rancher,L=willich,ST=nrw,C=de

Valid from 2024-06-24T10:52:04.000Z to 2034-06-22T10:52:04.000Z

Certificate expires in 3649 days

```

After completing the SAML config setup the dashboard only shows

```

cert.pem (CN=tagetarl)

```

Regardless, it is all a match. (Side note: If the dashboard could be convinced to show the cert's fingerprint then this could make me even more sure of the match)

Note regarding names: Both Alexandre and I are devs for the same org, and he gave me access to the instance for testing.

I.e. I work under his name when editing my application (`aku-saml-so`) in the dev-88193867 okta instance.

* Mismatched signature and digest algorithms.

The dashboard shows

```

Signature Algorithm RSA_SHA256

Digest Algorithm SHA256

```

The logout request captured using the `saml tracer` plugin [2] contains

```

<ds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more*rsa-sha256\"/>

<ds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc*sha256\"/>

```

That is a match. See [2] for the entire captured request.

* The logout request is not signed at all

The captured logout request contains a full `<ds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig*\">` tag structure. See [2] for the complete captured logout.

So that looks good too.

* The cert in the request itself does not match the cert in the instance.

See [2] for the captured request with cert. Pulling the cert out and comparing against the local copy shows them as identical.

I already noted as my first check that the local cert is identical to the cert known to the okta instance.

* External validation

The https://www.samltool.com/validate_logout_req.php tool claims that the captured logout request is valid.

* The logout request is only partially signed.

The captured logout request [2] contains

```

<ds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig*enveloped-signature\"/>

<ds:Transform Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n*\"/>

```

It is my understanding that this means that the entire request signed.

* What else ?

At this point, while I am fine with the belief that there is something wrong on my side I also believe that the common possible causes are not the problem here. What else could be wrong ?

Something else in the SAML config of the instance and app ?

Footnote [3] shows my config, as copied out of the dashboard

It is really unfortunate that

the dash board does not show the cert fingerprint as a very good way of checking for cert mismatches without given out the entire cert.
the log entry of `invalid signature` is so opawue, with no details at all where the okta decided things were bad.

In hope of help,

Andreas

Single Sign-On

Top Rated Answers

6bbqh (6bbqh)
2 years ago
This question is resolved.

Talking with a different provider about other symptoms put me on the correct track.
The keyword is "detached signatures" in redirect mode.

Where the signature info is not embedded in the XML, but passed as "SigAlg", "Signature" query parameters. The client package used did not generate these for logout requests, just auth.
Luckily a PR was found providing the necessary fix to the package.

I have now made a proper successful SLO against OKTA.
Expand Post
Selected as Best

All Answers

6bbqh (6bbqh)
Edited June 26, 2024 at 8:22 AM
# Footnotes and pseudo attachments referenced in the description. Separate post because of description size limits

[1] https://dev-88193867-admin.okta.com/

[2] Logout request captured by `saml tracer` browser plugin, with the tags manually placed on separate lines for readability. Change ">\n<" to "><" to undo that transform.
```
<samlp:LogoutRequest xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" ID=\"id-d178b021c52ff250a13298fac85df88bf6a16daf\" Version=\"2.0\" IssueInstant=\"2024-06-24T11:05:26.69Z\" Destination=\"https://dev-88193867.okta.com/app/dev-88193867_akusamlslo_1/exkhnrs1os1iwEtGT5d7/slo/saml\">
<saml:Issuer Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:entity\">https://***/v1-saml/okta/saml/metadata</saml:Issuer>
<ds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/>
<ds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\"/>
<ds:Reference URI=\"#id-d178b021c52ff250a13298fac85df88bf6a16daf\">
<ds:Transforms>
<ds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\"/>
<ds:Transform Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/>
</ds:Transforms>
<ds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\"/>
<ds:DigestValue>hdmluiSmi5ycQoKzZr8rltM6Jg7pE0L6wfA4Y/lDcPI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>***</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>***</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:NameID NameQualifier=\"http://www.okta.com/exkhnrs1os1iwEtGT5d7\" SPNameQualifier=\"https://***/v1-saml/okta/saml/metadata\">admin-slo@bogus.tester</saml:NameID>
</samlp:LogoutRequest>
```

[3] `aku-saml-slo` app config in [1]
```
App Settings
Application label aku-saml-slo
Application visibility Do not display application icon to users
Provisioning Enable SCIM provisioning
Auto-launch Auto-launch the app when user signs into Okta.
Application notes for end users
Application notes for admins

SAML Settings
GENERAL
Single Sign On URL https://***/v1-saml/okta/saml/acs
Recipient URL https://***/v1-saml/okta/saml/acs
Destination URL https://***/v1-saml/okta/saml/acs
Audience Restriction https://***/v1-saml/okta/saml/metadata
Default Relay State
Name ID Format EmailAddress
Response Signed
Assertion Signature Signed
Signature Algorithm RSA_SHA256
Digest Algorithm SHA256
Assertion Encryption Unencrypted
SAML Single Logout Enabled
SAML Signed Request Disabled
Signature Certificate cert.pem (CN=tagetarl)
authnContextClassRef PasswordProtectedTransport
Honor Force Authentication Yes
Assertion Inline Hook None (disabled)
SAML Issuer ID http://www.okta.com/${org.externalKey}
```

Expand Post
Mihai N. (Okta, Inc.)
2 years ago
Hi @6bbqh (6bbqh) , Thank you for reaching out to the Okta Community!

For security reasons, I strongly recommend redacting your post to not display sensitive information on the public forum. The Okta Community Questions forum isn't really meant for in-depth troubleshooting.
If you have an account with us please open a case and work with my colleagues from the Support Team. They'll be able to access additional tools and resources to help you get to the bottom of it.

In the meantime, if you are the app owner please check the following documentation for possible relevant information that might explain what is going on.
If you are not the app owner, I recommend checking with the service provider to confirm if the app supports SLO.

Regards.

--
Ask Us Anything thru 7/14: Okta WIC leadership want to hear from you
Expand Post
6bbqh (6bbqh)
2 years ago
> I strongly recommend redacting

Removed the embedded cert (local self-signed), and internal host name.

> In the meantime, if you are the app owner please check the following documentation for possible relevant information that might explain what is going on.

Reading the documentation I note that looks to be out of date with respect to the latest UI.

None of
```
SLO participation: Select the checkbox to allow your SAML app to participate in IdP-initiated SLO. Users are signed out of the app when any other app, or Okta, initiates single logout.
Request URL: Enter the URL where you want Okta to send the IdP-initiated logout request. For example:
http://myapp.exampleco.com/saml/logout
Select how your app expects Okta to send the IdP-initiated logout request:
HTTP POST: Send additional data in the request body
HTTP Redirect: Send data as query parameters in the request URL
Select Include user session details to include the session index (
sessionIndex
) as part of the IdP-initiated logout request. This ends a specific user’s session rather than all active user sessions within that browser.
```

looks to be present, and the preceding elements have different names.

That said, the only thing there was the `SP Issuer` I had not filled out.
Added the ACS url there per these docs.
It made no difference.
I will open a support case now.

Thank you for your help.

Expand Post
6bbqh (6bbqh)
2 years ago
This question is resolved.

Talking with a different provider about other symptoms put me on the correct track.
The keyword is "detached signatures" in redirect mode.

Where the signature info is not embedded in the XML, but passed as "SigAlg", "Signature" query parameters. The client package used did not generate these for logout requests, just auth.
Luckily a PR was found providing the necessary fix to the package.

I have now made a proper successful SLO against OKTA.
Expand Post
Selected as Best

This question is closed.

Recommended content

Forum

Invalid Name ID during Single Logout

Forum

Single Logout Response not working ,getting Invalid signature in okta system log

Forum

SAML 2.0 invalid signature

Forum

OKTA SAML SLO Response Status "Authnfailed" and in the okta system log it is updated as invalid signature error.

Loading

SAML logout response reports `urn:oasis:names:tc:SAML:2.0:status:AuthnFailed`, okta logs `Invalid Signature`, what was done wrong ?