[Okta] 401 Nonce Verification Failed

[echoboomer]

I've set this up following the directions for Okta auth precisely and when I visit the CNAME address that points to this CloudFront distribution, I'm redirected to Okta for authentication. Once I authenticate, I receive an Error 401 Nonce Verification Failed message. Okta logs show that I authenticated successfully. Any thoughts on what is causing this?

[echoboomer]

Is there an update on a potential solution for this?

[echoboomer]

I switched to using Google auth and I'm getting the exact same issue.

[payton]

@echoboomer Running through a fresh setup now to see if I can recreate the issue. Will update soon.

[echoboomer]

@payton I will say that I tried this again yesterday using Google auth and it worked out fine as long as I used the CNAME in front of the Cloudfront distro instead of the URL of the distro itself for the redirect_uri field.

[payton]

@echoboomer I see... Yes, that would cause a problem if using a CNAME. Two action items can be resolved from this issue:

1. Explore alternative language for the nonce verification failed condition
2. Update documentation to account for use of alternative domain names

[petersonsbuild]

@payton Hello - to resurrect this particular issue: I'm getting the same 401 Nonce verification failed error with Azure and have set the correct redirect_uri field as indicated above. For all I can tell, this should work but I get the error no matter what I try - any feedback on how I can troubleshoot this to get to the bottom of what the problem may be?

[rjkar]

@payton - Same getting "Nonce Verification Failed Error 401" after authentication, we have CDN(www.example.com) and origin(xyz.origin.com) will call the lamda to authenticate user. enduser hit the CDN-->origin-->lamda-->AAD.

[cpiwarski]

Running across this problem with okta and cloudfront. It would be great to attach a cname to the cloudfront distribution directly.

[TheBitDrifter]

Hey guys I'm just an intern currently leveraging this repo for my project. I'm pretty green to this stuff but may have some helpful insights regarding this issue.

Context:

For my project, I have an s3 bucket serving a static site through CloudFront. I was given a domain to route the distro through. I needed to be able to access my distro through the root domain and also the www. subdomain. However, this creates a problem:

The Problem

If the domain initially being redirected to your Oauth provider does not match the the redirect_uri keys inside config.json, you will get the Nonce 401 error. Here an example to clarify:

An example of the problem

Lets say my domain is: mydomain.com and my redirect uri is www.mydomain.com/callback

If I login through www.mydomain.com everything will work fine However, if I log in through mydomain.com I will get the nonce validation If I set the redirect uri to mydomain.com then the www. subdomain will get the error instead

Why I think this happens:

Currently when the lambda is first invoked, it calls a redirect function that sends you the Oauth provider(google in my case). Before redirecting you, this function uses a cryptography library to generate a random "nonce" string. The library is also used to create a hash from the nonce string too. The nonce string is passed to google while the hash is serialized inside a cookie-> inside the headers of your CURRENT DOMAIN**** (this is where I think the root of the issue occurs).

When you are coming back from the Oauth provider(the lambda checks for this) and decodes the callback token from google. It gets the nonce string from the google token and then tries to retrieve hash from the cookie. If your entry domain isn't the same as the redirect uri the cookie will not be inside the headers on the callback. This will cause the Nonce validation to error resulting in the 401 error.

My solution

In my case I was able to fix this(at least I think so, I'm pretty new to this stuff) by adding a domain key(pointing to my root domain-> mydomain.com for example) whenever the lambda was writing a new nonce cookie.

Here is the behavior of the domain key

If omitted(the domain key), defaults to the host of the current document URL, not including subdomains. Contrary to earlier specifications, leading dots in domain names (.example.com) are ignored. Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included. If omitted, defaults to the host of the current document URL, not including subdomains. Contrary to earlier specifications, leading dots in domain names (.example.com) are ignored. Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included. from: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

In other words, inside index.js if you find something like this:

                 {
                        "key": "Set-Cookie",
                        "value" : cookie.serialize('NONCE', n[1], {
                          path: '/',
                          expires: new Date(1970, 1, 1, 0, 0, 0, 0)
                        })
                 }

-or-

                 {
                        "key": "Set-Cookie",
                        "value" : cookie.serialize('NONCE', "", {
                          path: '/',
                          expires: new Date(1970, 1, 1, 0, 0, 0, 0)
                        })
                 }

edit it to this:

           {
                        "key": "Set-Cookie",
                        "value" : cookie.serialize('NONCE', '', {
                          path: '/',
                          domain: "yourRootDomain.com",
                          expires: new Date(1970, 1, 1, 0, 0, 0, 0)
                        })
            }

Conclusion

Always I might be totally off but I had to do a lot of digging to fix my issue so I thought I would share with people who might benefit!