okta/okta-aspnet

okta-aspnet

okta-aspnet's Issues

Update ASP.NET Core quickstart with beta code

Update this quickstart: https://developer.okta.com/quickstart/#/okta-sign-in-page/dotnet/aspnetcore
(Both the Sign-in Page version and API version)

• Demonstrate using the Okta.AspNet package package and new code (this will require the user to check Include prerelease or use -pre when installing)
• Include the below beta warning

The Okta.AspNetCore package is currently in beta. We'd love to get feedback while we build the library. Until the library is stable, Okta doesn't recommend using it for production applications. Refer to the sample app in the meantime for a supported way to get this working.

Add Support for multiple client id validation in StrictTokenHandler

I would like to use this nuget package to hookup my Web API, however my API serves multiple clients and this middleware will only allow for a single client to be used because of the StrictTokenHandler.cs validation.

app.UseOktaWebApi(new OktaWebApiOptions()
            {
                OktaDomain = "https://<mydomain>",
                ClientId = "myclientid",       // I need a way to pass in multiple client ids here
                AuthorizationServerId = "myauthserverid"
            });

I would like to propose either of the following options:

• change ClientId to an array so it can hold a whitelist of client ids that can be validated in the StrictTokenHandler.cs
• allow for injection of another custom TokenHandler via the OktaWebApiOptions

SignOutResult() Invalid_token Error

My application was working fine using the Okta.AspNetCore v 1.1.4 middleware. When I updated it to version 1.1.5, my app started throwing a 400 bad request error in the following line of code while logging out:

return new SignOutResult(new[] { OktaDefaults.MvcAuthenticationScheme, CookieAuthenticationDefaults.AuthenticationScheme });

I rolled the NuGet package back to version 1.1.4 and everything is working again.

Would it be possible to get a working sample with the latest versions of your dll and identitymodel 4?

Would it be possible to get a working sample with the latest versions of your dll and identitymodel 4?
okta-hosted-login is the one i’d like
Identity Model 4.0 and Okta Asp.Net 1.4.0

Thanks
–steph

Adding Okta.AspNet.Mvc.IntegrationTests

• Research best approaches to run integration tests with ASP.NET 4.X + OWIN.
• Implement integration tests and configure them using env vars
• Add tests to cake

Add & update configuration guards

From https://oktawiki.atlassian.net/wiki/spaces/PM/pages/552049922/Proposal+configuration+copypasta+guard

• OktaDomain is null or empty
• OktaDomain contains {yourOktaDomain}
• OktaDomain contains -admin.okta.com, -admin.oktapreview.com, or -admin.okta-emea.com
• OktaDomain ends with .com.com
• Client ID is null or empty
• Client ID contains {clientId}

For Okta.MvcOptions:

• Client secret is null or empty
• Client secret contains {clientSecret}

Some of these are implemented already, but we need to update the error messages to the new error strings mentioned in the wiki.

Update ASP.NET quickstart with beta code

Update this quickstart: https://developer.okta.com/quickstart/#/okta-sign-in-page/dotnet/aspnet4
(Both the Sign-in Page and API versions)

• Demonstrate using the Okta.AspNet package package and new code (this will require the user to check Include prerelease or use -pre when installing)
• Include the below beta warning

The Okta.AspNet package is currently in beta. We'd love to get feedback while we build the library. Until the library is stable, Okta doesn't recommend using it for production applications. Refer to the sample app in the meantime for a supported way to get this working.

Chore: update readme and documentation after publishing

Chore: rename some configuration classes

• OktaOptions to OktaWebOptions
• OktaMvcOptions to OktaWebMvcOptions

Then:

• Change the namespace of OktaWebOptions to namespace Okta
• Change the namespace of OktaWebMvcOptions to namespace Okta
• Change the namespace of OktaWebApiOptions to namespace Okta

Add PostLogoutRedirectUri property in the Okta.AspNetCore.OktaMvcOptions

add claims locally for .net core

Would be nice to be able to inject few claims into User.Claims after a user is authenticated with Okta, based on some local user storage attributes.

Microsoft describes a way to achieve that in https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/additional-claims?view=aspnetcore-2.2. But it requires access to OpenId.Events hidden by OktaMvcOptions.

Is there any workaround?

Update README with token customization examples

Document all public methods

We have several public methods that are not documented in the code.

Update OktaMvcOptions ASP.NET Core reference

RedirectUri has to be renamed to CallbackPath.

Configuring Okta.AspNet.WebApi.IntegrationTests from environment variables and adding these tests to Cake

Now we have integration tests but are configured via web.config.
We have to change this approach to get the configuration parameters from the environment variables. By doing this, we can set up our CI server and run this tests on it.

Add troubleshooting section

Let's add a section to the readme called Troubleshooting. I moved this from the sign users in guide:

---

Note: If you are using .NET framework <4.6 or you are getting the following error: "The request was aborted: Could not create SSL/TLS secure channel." Make sure to include the following code in the Application_Start or Startup:

// Enable TLS 1.2
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

An Alternative (Simpler) Initialization

The quick start docs for .NET Core have a code snippet for the initial Okta middleware setup to be used in the ConfigureServices method.

(This one 👇)

services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = OktaDefaults.MvcAuthenticationScheme;
})
.AddCookie()
.AddOktaMvc(new OktaMvcOptions
{
    OktaDomain = "https://{yourOktaDomain}",
    ClientId = "{clientId}",
    ClientSecret = "{clientSecret}"
});

// ... the rest of ConfigureServices
services.AddMvc();

This is pretty simple 😊

I just want to throw out an alternative option for devs who:

• Want to test out the middleware a bit more quickly
• Don't need any additional customization

It might look something like this (whatever the name might be):

services.AddOktaCookieAuth(configuration);

This would internally do what the above snippet does.

It would reduce the using statements from 2 to 1 - removing the need for:

using Microsoft.AspNetCore.Authentication.Cookies;

It's not a big deal but it's a tiny "win." And tiny "wins" over time can compound, right?

This would match some of the conventions built into .NET Core too. For example, adding the entire MVC infrastructure is simply:

services.AddMvc();

Under the covers that would add a bunch of stuff that the dev could otherwise add himself. But the simple convenience is part of what makes .NET Core so great.

Other pros:

• Could lead to simplifying the "quick start" docs a tiny bit
• Help make demos etc. a bit quicker to get started

If you guys think this is a good idea I'd be up for implementing that. Otherwise, no harm done 🤣

Thanks! Keep up the good work guys 👌

Allow custom JwtBearerEvents to allow SignalR to work with Bearer tokens.

OktaWebApiOptions should include an option to set Events (JwtBearerEvents). This is needed to allow SignalR to work with Bearer tokens. See the example at https://docs.microsoft.com/en-us/aspnet/core/signalr/authn-and-authz?view=aspnetcore-2.2

Library User-Agent

This library should report the user agent okta-aspnet/{ver} as described here: https://oktawiki.atlassian.net/wiki/spaces/PM/pages/237672215/User+Agents

• Create a class that generates the user agent string (you can use this for inspiration 😄)
• Add this user agent to requests to /oauth2/default/v1/keys
• Add this user agent to /authorize requests

POST /authorization-code/callback throws 500

I followed the quick start and authentication seems to be working for the most part. But we're seeing a few 500's in our log files for POST requests to /authorization-code/callback. It definitely does not happen every time, but we're seeing it periodically in our logs from other users.

I haven't created /authorization-code/callback endpoint in my project and I'm not sure how that endpoint is getting called.

The exception in the log files with the 500 is:

System.Exception:
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1+<HandleRequestAsync>d__12.MoveNext (Microsoft.AspNetCore.Authentication, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware+<Invoke>d__6.MoveNext (Microsoft.AspNetCore.Authentication, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware+<Invoke>d__7.MoveNext (Microsoft.AspNetCore.StaticFiles, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware+<Invoke>d__7.MoveNext (Microsoft.AspNetCore.StaticFiles, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware+<Invoke>d__6.MoveNext (Microsoft.AspNetCore.Diagnostics, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
Inner exception System.Exception handled at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1+<HandleRequestAsync>d__12.MoveNext:

Report different user-agent strings for ASP.NET Core and ASP.NET 4.5

Code examples not working - OktaDomain not being picked up in settings files

We've decided to put Okta support on hold. I could not find any AspNetCore projects or MVC 5 code examples on GitHub repository that work and no response from support.

Test Name: Okta.AspNetCore.Mvc.IntegrationTest.MiddlewareShould.RedirectWhenAccessToProtectedRouteWithoutSignedInAsync
Test FullName: Okta.AspNetCore.Mvc.IntegrationTest.MiddlewareShould.RedirectWhenAccessToProtectedRouteWithoutSignedInAsync
Test Source: C:\Users\jabil.100004892\okta-aspnet\Okta.AspNetCore.Mvc.IntegrationTest\MiddlewareShould.cs : line 41
Test Outcome: Failed
Test Duration: 0:00:00.001

Result StackTrace:
at Okta.AspNet.Abstractions.OktaWebOptionsValidator`1.Validate(OktaWebOptions options) in C:\Users\jabil.100004892\okta-aspnet\Okta.AspNet.Abstractions\OktaWebOptionsValidator.cs:line 33
at Okta.AspNetCore.OktaAuthenticationOptionsExtensions.AddOktaMvc(AuthenticationBuilder builder, OktaMvcOptions options) in C:\Users\jabil.100004892\okta-aspnet\Okta.AspNetCore\OktaAuthenticationOptionsExtensions.cs:line 25
at Okta.AspNetCore.Mvc.IntegrationTest.Startup.ConfigureServices(IServiceCollection services) in C:\Users\jabil.100004892\okta-aspnet\Okta.AspNetCore.Mvc.IntegrationTest\Startup.cs:line 29
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.ConfigureServices(IServiceCollection services)
at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()
at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
at Microsoft.AspNetCore.TestHost.TestServer..ctor(IWebHostBuilder builder, IFeatureCollection featureCollection)
at Okta.AspNetCore.Mvc.IntegrationTest.MiddlewareShould..ctor() in C:\Users\jabil.100004892\okta-aspnet\Okta.AspNetCore.Mvc.IntegrationTest\MiddlewareShould.cs:line 32
Result Message:
System.ArgumentNullException : Your Okta URL is missing. You can copy your domain from the Okta Developer Console. Follow these instructions to find it: https://bit.ly/finding-okta-domain
Parameter name: OktaDomain

RedirectUri property missing from Okta.AspNetCore package

I need to set the RedirectUri because my app is running behind a virtual directory. Setting that up locally in Core is a bit messy right now, so it might not be configured somewhere it needs to be. In any case Okta is taking http://localhost/MyApp and turning the RedirectUri to just http://localhost. I'm guessing this would affect apps behind a proxy as well.

Support Auth code flow

We use .Net 4.6.1 MVC and have seen that only the hybrid flow is supported and the response type is hard coded into the response.

Can you introduce a new feature to support the auth code flow so we follow OKTA's own best practises of avoiding the hybrid flow where possible.

Details on package set-up below:

Thanks in advance.

<package id="Okta.AspNet" version="1.4.0" targetFramework="net461" />
<package id="Okta.AspNet.Abstractions" version="3.0.2" targetFramework="net461" />
<package id="Okta.Sdk" version="1.4.1" targetFramework="net461" />
Sample Application setup OKTA documentation that we follow is here - https://developer.okta.com/quickstart/#/okta-sign-in-page/dotnet/aspnet4

Line of code where the response type is hardcoded to “code id_token” in the SDK – Line no 50 in the class BuildOpenIdConnectAuthenticationOptions -
https://github.com/okta/okta-aspnet/blob/master/Okta.AspNet/OpenIdConnectAuthenticationOptionsBuilder.cs

Hook up build script to repo

• Builds should run on every commit
• Merging to master should be blocked on a successful build

Switch to OktaDomain

Background: https://oktawiki.atlassian.net/wiki/spaces/UX/pages/470681125/Developer+Experience+-+Okta+Domain+Labels

• Switch OrgUrl to OktaDomain in options object
• Update quickstarts to use https://{yourOktaDomain} (no .com)

Include .NET 4.5.2 projects to be built by Travis

Add .net core 3 support

This SDK does not work dotnet core 3.0. Can we have the SDK build for the newer version of dotnet?

How to validate access tokens against expiration time

How to validate tokens against expiration time in .net core.

Update ASP.NET quickstart for stable release

After we release a 1.0.0 stable, update the ASP.NET quickstart (both redirect and API versions):

• Remove the beta warning

Investigate better error message when OIDC discovery fails

ASP.NET (4.x especially) tends to throw really unhelpful errors when retrieving the discovery document fails. For example: https://devforum.okta.com/t/401-status-on-login/3615

Is it possible to hook into any part of the MS OIDC middleware to detect this, and at the very least, throw a more helpful error message?

Add supported .NET versions to readme

In the root README.MD file, we should mention which versions of .NET Framework and .NET Standard these packages are compatible with. Like this: https://github.com/okta/okta-sdk-dotnet#getting-started

PKCE support

Hello,

Does this package supports Authorization Code + PKCE ?

Thanks!

Extract documentation from readme

The readme currently serves 4 different use cases (ASP.NET 4.x/Core + MVC/Web API). Let's split it up so the readme only contains:

• Okta ASP.NET middleware
• What you need
• Links to quickstarts, doc pages*, and sample applications
• Contributing
• Getting help

*The doc pages will be new. Create a file in a new docs folder for each of:

• ASP.NET 4.x (MVC) - docs/aspnet4x-mvc.md
• ASP.NET 4.x (Web API) - docs/aspnet4x-webapi.md
• ASP.NET Core (MVC) - docs/aspnetcore-mvc.md
• ASP.NET Core (API) - docs/aspnetcore-api.md

Each one of these new pages should contain:

• Installing the package
• Usage example
• Configuration reference

Self-hosted samples redirect to Okta instead of the self-hosted login

When you are not authenticated and try to access a controller decorated with [Authorize] attribute, it redirects to Okta instead of the local sign in page.

Library configuration checks

Can you do a check to make sure the config checks in this library match the wiki?

https://oktawiki.atlassian.net/wiki/spaces/PM/pages/552049922/Library+configuration+checks

I've made a few (final) updates.

Fix NameClaimType to solve ValidateAntiForgeryToken issue on ASP.NET MVC

It appears that at https://github.com/okta/okta-aspnet/blob/master/Okta.AspNet/OktaMiddlewareExtensions.cs#L94 we are setting the name claim type to the literal string "name" when asp.net expects it to be set to ClaimTypes.NameIdentifier.

This is causing

System.InvalidOperationException: 'A claim of type 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier' or 'http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider' was not present on the provided ClaimsIdentity. To enable anti-forgery token support with claims-based authentication, please verify that the configured claims provider is providing both of these claims on the ClaimsIdentity instances it generates. If the configured claims provider instead uses a different claim type as a unique identifier, it can be configured by setting the static property AntiForgeryConfig.UniqueClaimTypeIdentifier.'

when using the ValidateAntiForgeryToken functionality in ASP.NET.

We probably need to either update the "name" literal to ClaimTypes.NameIdentifier or add a 2nd claim type of ClaimTypes.NameIdentifier.

A workaround is to include AntiForgeryConfig.UniqueClaimTypeIdentifier = "name"
in a site's "startup.cs"

Bump Asp.Net projects versions

Okta.AspNet.Abstractions -> 1.1.0
Okta.AspNet & Okta.AspNetCore -> 1.2.0

Features

• Report user agents #48

@nbarbettini ^

Update ASP.NET Core quickstart for stable release

After we release a 1.0.0 stable, update the ASP.NET Core quickstart (both redirect and API versions):

• Remove the beta warning

Chore: update dependencies

A few internal dependencies have patch versions we can apply. After that, re-test to make sure nothing broke.

Include id_token in ResponseType

In the AspNet version of the extensions, the ResponseType is set to do code and id_token

app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
    ClientId = options.ClientId,
    ClientSecret = options.ClientSecret,
    Authority = issuer,
    RedirectUri = options.RedirectUri,
    ResponseType = OpenIdConnectResponseType.CodeIdToken,
    Scope = scopeString,
    PostLogoutRedirectUri = options.PostLogoutRedirectUri,
    TokenValidationParameters = tokenValidationParameters,
    Notifications = new OpenIdConnectAuthenticationNotifications
    {
        AuthorizationCodeReceived = tokenExchanger.ExchangeCodeForTokenAsync,
        RedirectToIdentityProvider = BeforeRedirectToIdentityProviderAsync,
    },
});

However, in the AspNetCore version, it's just code:

builder.AddOpenIdConnect(oidcOptions =>
{
    oidcOptions.ClientId = options.ClientId;
    oidcOptions.ClientSecret = options.ClientSecret;
    oidcOptions.Authority = issuer;
    oidcOptions.CallbackPath = new PathString(options.CallbackPath);
    oidcOptions.SignedOutCallbackPath = new PathString(OktaDefaults.SignOutCallbackPath);
    oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
    oidcOptions.GetClaimsFromUserInfoEndpoint = options.GetClaimsFromUserInfoEndpoint;
    oidcOptions.SaveTokens = true;
    oidcOptions.UseTokenLifetime = false;
    oidcOptions.BackchannelHttpHandler = new UserAgentHandler("okta-aspnetcore", typeof(OktaAuthenticationOptionsExtensions).Assembly.GetName().Version);

    var hasDefinedScopes = options.Scope?.Any() ?? false;
    if (hasDefinedScopes)
    {
        oidcOptions.Scope.Clear();
        foreach (var scope in options.Scope)
        {
            oidcOptions.Scope.Add(scope);
        }
    }

    oidcOptions.TokenValidationParameters = new DefaultTokenValidationParameters(options, issuer)
    {
        ValidAudience = options.ClientId,
        NameClaimType = "name",
    };

    oidcOptions.Events.OnRedirectToIdentityProvider = BeforeRedirectToIdentityProviderAsync;
});

This prevents returning group claims since the groups scope only works with ID tokens. Is this an intentional change in behavior?

Okta Widget + ASP.NET Core

I haven't seen any documentation on how to use Okta on ASP.NET (Core or pre-Core) with a social IdP (Google, Facebook, etc). Getting up and running with Okta via the OIDC middleware is a breeze, but it doesn't account for the social workflow as far as I can see. In my scenario, I'd like to support Okta user account authentication in addition to social.

The documentation makes it seem like you have to go down the path of using Javascript and building your own sign-in experience. I have this workflow working in the sense that I can get JSON returned with an id_token and claims, but that doesn't hook into the ASP.NET security model very well (my app is not a SPA).

Is there a way to leverage the OIDC middleware with a social IdP workflow?

Turn on Travis testing

Make SDK available via middleware

When I use the middleware in my ASP.NET project, I should also get access to the Okta SDK. The goal is to make it super easy for a developer to start using the middleware for basic authn/authz, and then optionally use the SDK to do additional tasks via the Okta API.

However, we should only do this after Okta.Sdk has a stable release. (not prerelease as it is today)

• Make Okta.AspNet depend on Okta.Sdk so the SDK is pulled in automatically by Nuget
• Add an optional configuration property for an Okta API token. If this property is present, automatically configure the SDK
• Provide a way to get access to the SDK in the request context, like HttpContext.GetOwinContext().GetOktaSdk() (or a better pattern)
• Use the SDK's ScopedClient functionality to add the middleware's user-agent to SDK calls

Bump version to 1.0.0

Remove beta from project version.

Override DefaultTokenValidationParameters

Hi,

I'm working in a project that contains 2 different apps (iOS Native App,Web App) and a middleware.
Both apps need to login using Okta SDK and then call some endpoints in the middleware, that should take the access token and validate it also using the Okta SDK.

The problem is that i get different audiences from both apps...
in the iOS app i get api://default but in the web app i get the ClientId and i can't find a way to make both work.

What can i do to fix this? is it possible to expose DefaultTokenValidationParameters and let user override some of the values?

Update docs and samples to ASP.NET Core 2.2

ASP.NET Core 2.2 has been out for a while now. We should update our quickstarts, readmes, and sample apps to show code and instructions compatible with ASP.NET Core 2.2.

Add CustomAuthPage Url as a option.

After working with Okta via the standard OWIN middleware (not this repo) I noticed that the asp.net/OWIN way of redirecting to a custom authentication page is rather heinous. It requires tinkering with the Cookie and OIDC middleware bits, including AuthenticationMode, etc...all just to redirect to a different domain/url.

As a convenience for developers (who don't like writing excess c# to do a simple task) adding CustomAuthPageUrl (or some variation of) could be extremely helpful. Thanks!

Expand Configuration Reference section in the README

Similar to what we do here: https://github.com/okta/okta-sdk-dotnet#configuration-reference

Token expiration - Opera Web Browser

Hi,

An end user told us that his session in the application never expired. The first thing I did was try to replicate the issue.
I have tested with Chrome, Firefox and Edge and worked perfectly. However the end user uses an Opera Web Browser(https://www.opera.com/) and indeed when I access an application using this browser the session never expires. I remained authenticated forever what is a security flaw, because if I revoke its access the application access remain working.
The application is a ASP.NET MVC Core 2.2 and Okta.AspNetCore 1.1.5.
I have tested the token in the Okta Portal and the token expiration attributes looks correct.
"iat": 1579862469,
"exp": 1579866069,
Did someone experience any issue like this?