.NET MVC Project - using Sign In Widget

Hi All,

I have been playing around with Okta for a couple of days and so far very impressed. I have been struggling with something however…

I am building a .Net MVC App (crucially this is not a Web API project). I have been using the Sign In Widget which works well but I couldn’t find any documentation for how to get this to place nice with MVC/Owin authentication (the documentations seems to suggest more using the Okta sign in page but I need to customize the look and feel of the login to match the rest of the app).

My current work around is to redirect the Javascript sign in page to to the login method for the Okta sign in page (which seems to work!) but I’m fairly sure this is a silly round about way to achieve what I’m trying to do…

Happy to post more examples of code etc if any of this is unclear but hoping someone may have done this before or be able to point me in the direction of some tutorials on how to set this up.

Many thanks!

Hey Louis!

The easiest way is to redirect to the Okta hosted sign-in page, as you mentioned, although you can’t fully customize the page (yet). We’re rolling out a feature soon that will allow you to totally customize the hosted sign-in page so you can make it look however you want. :+1:

In the meantime, a workaround is your best bet. We don’t have a tutorial for this right now, sorry. If you post some code snippets, I can take a look at what you have and offer suggestions.


Hi Nate,

Thanks for the quick reply! My code currently looks like this…

I have a standard JS Login page (taken almost line for line from one of your examples).

On success I call setCookieAndRedirect and redirect to the Okta hosted sign in page…

My startup class is below

public class Startup
        public void Configuration(IAppBuilder app)
            // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=316888


        private void ConfigureAuth(IAppBuilder app)

            app.UseCookieAuthentication(new CookieAuthenticationOptions
                AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,

            var clientId = ConfigurationManager.AppSettings["okta:ClientId"].ToString();
            var clientSecret = ConfigurationManager.AppSettings["okta:ClientSecret"].ToString();
            var issuer = ConfigurationManager.AppSettings["okta:Issuer"].ToString();
            var redirectUri = ConfigurationManager.AppSettings["okta:RedirectUri"].ToString();

            app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
                ClientId = clientId,
                ClientSecret = clientSecret,
                Authority = issuer,
                RedirectUri = redirectUri,
                ResponseType = "code id_token",
                UseTokenLifetime = false,
                Scope = "openid profile",
                PostLogoutRedirectUri = ConfigurationManager.AppSettings["okta:PostLogoutRedirectUri"].ToString(),
                TokenValidationParameters = new TokenValidationParameters
                    NameClaimType = "name"
                Notifications = new OpenIdConnectAuthenticationNotifications
                    RedirectToIdentityProvider = context =>
                        if (context.ProtocolMessage.RequestType == OpenIdConnectRequestType.LogoutRequest)
                            var idToken = context.OwinContext.Authentication.User.Claims.FirstOrDefault(c => c.Type == "id_token")?.Value;
                            context.ProtocolMessage.IdTokenHint = idToken;

                        return Task.FromResult(true);
                    AuthorizationCodeReceived = async context =>
                        // Exchange code for access and ID tokens
                        var tokenClient = new TokenClient(
                            issuer + "/v1/token", clientId, clientSecret);
                        var tokenResponse = await tokenClient.RequestAuthorizationCodeAsync(context.ProtocolMessage.Code, redirectUri);

                        if (tokenResponse.IsError)
                            throw new Exception(tokenResponse.Error);
                        var userInfoClient = new UserInfoClient(issuer + "/v1/userinfo");
                        var userInfoResponse = await userInfoClient.GetAsync(tokenResponse.AccessToken);

                        var identity = new ClaimsIdentity();

                        identity.AddClaim(new Claim("id_token", tokenResponse.IdentityToken));
                        identity.AddClaim(new Claim("access_token", tokenResponse.AccessToken));
                        if (!string.IsNullOrEmpty(tokenResponse.RefreshToken))
                            identity.AddClaim(new Claim("refresh_token", tokenResponse.RefreshToken));

                        var nameClaim = new Claim(ClaimTypes.Name, userInfoResponse.Claims.FirstOrDefault(c => c.Type == "name")?.Value);

                        context.AuthenticationTicket = new AuthenticationTicket(
                            new ClaimsIdentity(identity.Claims, context.AuthenticationTicket.Identity.AuthenticationType),

This actually does work pretty well - it seems though Okta is reading the cookie set by the JS page and therefore doesn’t prompt for credentials and instead just creates me a session and logs me in. This is the exact behavior I was hoping to achieve however it didn’t seem like I was doing it the right way.

Long term formatting the Okta hosted login page would definitely be the cleanest way of doing this (although even then I would rather it appear under our domain as some of the data we deal with is very sensitive and clients may understand why they are on a “different website” to enter their credentials).

Looking forward to hearing your feedback on this.

Kind Regards,

These are both features (Custom Hosted Login Page & Custom URL Domain) that are in beta and we are trying to get them out as soon as possible.

I hope you all are pumped, because I am :slight_smile:

1 Like

Absolutely - my existing method seems to work but my “concern” is I’m not that sure why! Will definitely switch it over as soon as that becomes an option :slight_smile:

Can’t wait to see those options in an upcoming version!


Your approach looks fine to me. It works because the Okta hosted page checks whether the Okta cookie exists already (representing an active session), and if so, it doesn’t bother prompting the user again.

It will definitely be cleaner when the full customization features roll out, but you’re fine for now. :+1:


Hi guys,

Any update on this or are these features still in Beta?



Still in beta, but making progress. I’ll post back here when they’re available for public testing.

Thanks Nate, appreciate it!


1 Like