I am posting this because I spent SEVERAL hours trying to figure out the problem late one nght and I want to share so no one else has to spend hours scouring the internet. I am rambling here, but I hope this helps one person.
We have Sitecore, which uses the OpenId Connect middleware. We are using Okta as our Identify Provider for our some 150k+ users. We use an Association Management Software (AMS) for our customer database. Our ‘create account’ process works like this, send the user to a custom register app, user enters email, password, name and address, customer is created in the AMS, then Okta, then log the customer in, then sent back to sitecore.
LOGIN
Click login
Create a NONCE.
It based on the time in ticks and 2 guids that are base 64 encoded concatenated)
for example: 637319180254671967.NWFiMTc1YjgtZTk5ZS00ODdhLTlkYjQtYWY2MmM2ZjA4NjE1NWYwOGY3MTUtYjk1Yi00Y2I5LThkMzQtNTQ1YmQyZDBiZWY4
Set cookie on device.
A hash based onthe this NONCE combined with ‘OpenIdConnect.nonce.’ is the name of the cookie. The value is something I do not know.
for example: OpenIdConnect.nonce.%2F6NrqZbUO7IbKJEdQyw5HwnAtQP56z4teE3W9LfYB0s%3D=; path=/; expires=Sat, 01-Aug-2020 22:48:45 GMT; secure; HttpOnly
the cookie name is OpenIdConnect.nonce.%2F6NrqZbUO7IbKJEdQyw5HwnAtQP56z4teE3W9LfYB0s%3D
the cookie value is
Send user to Okta’s authorize page.
In this case /oauth2/v1/authorize
Pass these values
Client ID
redirect uri
response_mode
response_type
scope
state
nonce
state and nonce are important for the trip back to the redirect uri
The login page takes all of that and stores it and returns back a state token.
For login, the user enters their credentials, the call (post) to /api/v1/authn with the credentials (username and password) and the state token.
If the credentials are valid, in that response, there a ‘next url’ that users are forwarded to:
for example. https:///login/step-up/redirect?stateToken=
based on this state token, the user is sent back to the original redirect uri, and includes state, code, and id_token.
The id_token is thw jwt that includes the customer’s claim, and original NONCE value.
The OpenId Connect middleware catches that and verifies the original cookie. It then takes that state value to know to send the user to the original page.
REGISTER
For original steps, the login page missed a couple of things that should have been sent to the register app.
The register app creates the customer in the AMS, creates the account in Okta, then authenticates using a post to /api/v1/authn, then goes to /oauth2/v1/authorize.
In this case /oauth2/v1/authorize
Client ID
redirect uri
response_mode
response_type
scope
nonce
sessionToken (SessionId from the /api/v1/authn call)
First, login was not passing the state value, therefore, sitecore was reporting a 404 error message when forwarding back to the original redirect uri
We updated the login page to pass the state to the register application.
We starting getting an error IDX10500 about signature validation.
We found that the register app was posting to /oauth2/default/v1/authorize instead of /oauth2/v1/authorize like Sitecore originally called.
We updated that, and got another error:
IDX10311: RequireNonce is ‘true’ (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don’t need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to ‘false’.
The register app was not grabbing the nonce that Sitecore (OpenId Connect middleware) was creating. It saved a cookie for the domain, but register app, or Okta wouldn’t have access to cookies for that.
So the update was to do exactly how login works. I had to modify the login page to pass the state token to the register app.
Now, after the account is created in the AMS, its created in Okta, the call (post) to /api/v1/authn with the credentials (username and password) and the state token. This is exactly what happens when a user logs in.
Since the credentials are valid (the account was just created), in that response, there a ‘next url’ that users are forwarded to:
https:///login/step-up/redirect?stateToken=
Based on this state token, the user is sent back to the original redirect uri, and it includes state, code, and id_token.
The id_token is the jwt that includes the customer’s claim, and original NONCE value.
The OpenId Connect middleware catches that and verifies the original cookie. It then takes that state value to know to send the user to the original page.