Try our conversational search powered by Generative AI!

OIDC Authorization with custom middleware

Vote:
 

Hello guys,

I have this strange use case that am trying to resolve. I have an EpiServer website (MVC). I use OIDC to authenticate users with OKTA. I use both Cookie Authentication (for the Web) and JWT authentication (for content delivery API) in the same startup.cs. 

Example Below:

            app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions { ..........  }

            app.UseJwtBearerAuthentication( new JwtBearerAuthenticationOptions  {  ........................ }

 All of these works fine. Now I have a use case where application will receive token (lets assume in query string). I need to check if the token came through and was valid, redirect the user to the resource. If token didn't existed then let next middleware pipeline trigger with the cookie authentication and normal flow continues.

I created a custom middleware and hooked it prior to CookieAuthentication middleware and can extract token , validate against OKTA but am having hard time redirecting the user to resource after successful validation. 

This is what I created

            app.UseCustomMiddleware();

And in the Custom Middleware I override the Task Invoke.

    public class CFASSOAuthentication : OwinMiddleware
    {
        public CFASSOAuthentication(OwinMiddleware next) : base(next) { }
        public async override Task Invoke(IOwinContext context)
        {

          //Extract the token here from the request object.

          //Validate token against OKTA

         // STUCK HERE ON REDIRECT

        }

   }

This may not be exactly EpiServer related issue but wondering if anyone had such scenario and could help me out here

#249940
Mar 12, 2021 4:03
Vote:
 

Support OwinMiddleware will be gone in CMS 12 (that's on .NET 5.0) and has always been a can of worms.

I would check if the token can be coming into a fixed URL and then use a regular Controller to process it or act in some shared place instead can work?

But to help with the Owin setup the order is important and returning the expected result to stop moving to next middleware, there might be some shared property you also need to set on the OwinContext to get a stoppage and get the redirect done.

#249992
Edited, Mar 13, 2021 7:31
Vote:
 

Hi Dileep

Can you please provide a bit more details what do you mean by "STUCK HERE ON REDIRECT" ? What do you get if you make call with ctx.Response.Redirect(url)  ? 

p.s. I think OKTA has provided middleware package that you can use. Maybe it's worrth to check out that too.

#250176
Mar 15, 2021 23:55
Dileep D - Mar 21, 2021 0:08
Vincent,
I have a use case where user would have already authenticated against OKTA and has the token which will be passed to my application. I have to implement a custom solution to check if token exists then validate and let user get into the application.
So I am trying to do this before even the cookie authentication triggers and user is presented with OKTA sign in widget.

Here is what am trying to do
public async override Task Invoke(IOwinContext context)
{

//Extract the token here from the request object.

var validatedToken = await ValidateToken(oktaToken, issuer, configurationManager);

if (validatedToken != null)
{
var id = new ClaimsIdentity(validatedToken.Claims);
context.Authentication.SignIn(id);
context.Response.Redirect("/"); // Stop the flow here and redirect user to the page
}
await Next.Invoke(context);

}
I can see the claims but after this my application still goes to the next pipeline and user authentication context is empty. I am not very clear with how this works so still researching on it. I checked some of OKTA's documentation but this is not a typical scenario there.
Vote:
 

I found two things in my cae which I updated and things started working. Firstly the ClaimsIdentity I had to construct using a different overload that takes authentication type, nameType and roleType. Secondly instead of just using claims from token I also added the claims from OKTA's userinfo end point as I found that there were some additional claims in this response which I needed (not that this was the issue). After these changes I could see that context.Authentication.SignIn has appropriate user object and authentication is true letting me to redirect into the resource. 

#252382
Apr 01, 2021 14:53
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.