Hi! We are currently doing testing on using Okta for our future applications. We are currently developing in ASP.Net 4x (MVC). We followed the guide and instructions that can be found here: Okta Auth Quickstart and here: ASP.NET 4.x MVC + Okta example. All works well when running in the localhost environment, can sign-in, get claims, and redirects properly after signing in the Okta Sign-in Page.
But when we move our code to our Test Server and following the same steps in the guide/instruction, made it’s own Application in Okta, updated the client ID, secret, redirect, etc everything match how the localhost was made only difference is the base URL
Login works, goes to the Okta Sign-in Page but when it tries to go back it looks like it’s trying, the code in the URL is changing but then ends up giving a http 400 error. We did change the redirect to match the location of where the app is placed plus the “authorization-code/callback”.
We did that part, we updated / created a new one for the test server. When we look at the okta logs, it successfully logs the user, authenticates and everything but we did notice that it does that several times like it’s in a loop. it loops for a while then then just gives up and serve the error page not found.
Also due to the setup in our environment we do have to use a proxy to let the calls to Okta go through which works fine when running in localhost at which I also assume will be fine in our test server.
Hey @JDizonCK, it sounds like aspnet might be stuck in a redirect loop. This can happen if the redirect back doesn’t work for some reason (and aspnet thinks it needs to redirect to the Okta sign-in page again, over and over).
Can you post your Startup.cs code and Application configuration in Okta?
Sure here’s the startup code. This is using VS 2017. Did a few minor changes to the Using statements.
using System.IdentityModel.Tokens; -switched/replaced with Microsoft.IdentityModel.Tokens
using Microsoft.IdentityModel.Protocols; - switched/replaced with Microsoft.IdentityModel.Protocols.OpenIdConnect
Did that change because the “TokenValidationParameters” line and “OpenIdConnectRequestType” line were complaining that it can’t see / find those and give those using as a solution.
Thank you.
Blockquote
using System;
using System.Configuration;
using System.IdentityModel.Tokens;
using System.Linq;
using System.Security.Claims;
using System.Threading.Tasks;
using IdentityModel.Client;
using Microsoft.IdentityModel.Protocols;
using Microsoft.IdentityModel.Protocols.OpenIdConnect;
using Microsoft.IdentityModel.Tokens;
using Microsoft.Owin;
using Microsoft.Owin.Security;
using Microsoft.Owin.Security.Cookies;
using Microsoft.Owin.Security.OpenIdConnect;
using Owin;
@nate.barbettini and @frederico.hakamine - Figured out the issue. Looks like the problem is with a security setting with our test server. Tested it with a different test server and it looks like its working on that one. Thank for the responses and suggestions!
Ok I take that back, sorry., after I tried on a different test server that’s on a different location/network it worked once, then tried again now getting a HTTP 400 Bad Request after log-in. Same issue.
@nate.barbettini@frederico.hakamine Updated Code based on the Github update (3-21-18), Updated Startup.cs and web.config. Run locally (LocalHost) works great, gets to the Okta sign-in, logs in and returns to the application. Deployed code to test server, created new application with same setting as local except the URI’s. Able to get to the Okta sign-in, can log-in and Okta logs shows success in log-in, but still fails to do the redirect back to the application. Loops/ tries several times as to redirect (monitors via Fiddler) then just fails to a HTTP 400. Even tried setting the redirect URI to the base uri or uri that I know exists and yet still unable to redirect.
And to make sure my code is not the problem, I used the code from GitHub, works locally but once on the test server it fails to do the redirect after log-in.
Appreciate the help. Trying / testing Okta for our company as a SSO solution but if it’s only working locally, is not a great solution.