Updated the sample Okta-hosted-login for dotnet48 Okta OIDC - the previous solution is broken

[rc3398]

You can modify the PR changes, README as needed. The existing solution with app.UseOktaMvc in Startup.cs does not work - for *dotnet48 and Okta OIDC. It will result in an infinite redirect loop between the webapp and Okta's AuthZ server due to a thrown error. This looks to be an issue with Okta's aspnet library and dotnet48 Owin's middleware. Instead, I modified the service to instead call app.UseOpenIdConnectAuthentication directly - which works. I believe the user claims are pulled from the user-info endpoint though and not the id_token. I was unable to get Single Logout to work, but I have not personally experimented with the solutions in item 2 below.

---

From README commit.

Okta-Hosted-Login with dotnet48 MVC webapp and Okta OIDC

This webapp is able to authenticate with Okta and fetch back the user claims and id_token payload in the Owin context. However, the below issues are present and will not be readily resolved (MSFT Owin framework issue). Therefore, we would not recommend using dotnet48 with Okta OIDC. Instead, please upgrade to dotnet core to use Okta OIDC or if that is not possible, use dotnet48 with Okta SAML.

Known Issues

1. The Owin context does not contain the access token. It is null at runtime. This is a known issue with the Owin framework and is not resolved by Microsoft. Therefore, the access token cannot be fetched from the Owin context. If you need to call external APIs, this will be an issue. The proposed solution here is to create an OktaAdapter that will fetch and validate the access token.
2. Global signout does not work. This app's signout will result in a redirect to the global Okta org's configured error page. Instead, you may need to try Okta's Single Logout URL (see link below) or manually clearing the cookies, Okta session, and local session. If using JWT to manage user session, configure a low expiry access token and long refresh token approach.
3. Okta's prescribed solution with app.UseOktaMvc in Startup.cs does not work. It will result in an infinite redirect loop between the webapp and Okta's AuthZ server due to a thrown error. This looks to be an issue with Okta's aspnet library and dotnet48 Owin's middleware. Instead, I modified the service to instead call app.UseOpenIdConnectAuthentication directly - which works. I believe the user claims are pulled from the user-info endpoint though and not the id_token.

[bryanapellanes-okta]

@rc3398 Thanks for your contribution! I've entered an internal issue for tracking and prioritization. OKTA-754489