Take the community feedback survey now.

Rejaie
Dec 18, 2017
  4966
(2 votes)

Web API + Service API + Cookie Auth Gotcha

I ran into an interesting problem while on a past project this year - when we turned on Service API via OWIN, my authorized Web API endpoints were returning a 401. We were using cookie authentication for the Web API endpoints. This baffled me a bit until I peeled back the code for Service API.

When one of the Service API's initialization modules executes, it bypasses the default host authentication by calling SupportDefaultHostAuthentication on the Global HTTP Configuration. This explains why my API endpoints weren't recognizing the logged in user's cookie. I came up with a workaround that ignored this call and used cookie authentication instead. See below - during this project, we were using Episerver 10.9.1, and Service API 3.0.1:

  • Add the following code to your OWIN startup. This code ultimately re-adds cookie auth to the Web API filter pipeline

    GlobalConfiguration.Configuration.Filters.Add(new HostAuthenticationFilter(DefaultAuthenticationTypes.ApplicationCookie));
  • In your API controller, decorate your controller or action with the System.Web.Http's Authorize Attribute

After I made these changes, I was able to access my authorized Web API endpoints. As a quick note, if you do use cookie authentication for your Web API endpoints, you may want to send an antiforgery token to protect against XSRF attacks. In this project, I sent the antiforgery token as a header and created a filter attribute that validated the token against the logged in user's cookie. In case anyone is interested, here was my setup:

  • In my master layout, I included a global antiforgery token. I placed this right after the <body> tag, but you can place this anywhere.

  • In my client side code, I sent the antiforgery token as a header. I called the __RequestVerificationToken.

  • On the server side, I created an attribute called UserValidateAntiForgeryTokenAttribute that inherited from FilterAttribute and IAuthorizationFilter. In the ExecuteAuthorizationFilterAsync method, I grabbed the cookie and token values and validated them against each other.
    public Task<HttpResponseMessage> ExecuteAuthorizationFilterAsync(HttpActionContext actionContext,
                CancellationToken cancellationToken, Func<Task<HttpResponseMessage>> continuation)
            {
                try
                {
                    // get headers
                    var headers = actionContext.Request.Headers;
    
                    // get cookie value
                    var cookieRvtValue = headers
                        .GetCookies()
                        .Select(c => c[AntiForgeryConfig.CookieName])
                        .FirstOrDefault()
                        ?.Value;
    
                    // get header value
                    var headerRvtValue = headers.GetValues("__RequestVerificationToken").FirstOrDefault();
    
                    // validate
                    AntiForgery.Validate(cookieRvtValue, headerRvtValue);
                }
                catch
                {
                    actionContext.Response = new HttpResponseMessage
                    {
                        StatusCode = HttpStatusCode.Forbidden,
                        RequestMessage = actionContext.ControllerContext.Request
                    };
                    var source = new TaskCompletionSource<HttpResponseMessage>();
                    source.SetResult(result);
                    return source.Task;
                }
                return continuation();
            }
        }
  • Decorate your Web API controller action with the attribute

    [UserValidateAntiForgeryToken]
    [Authorize]
    [HttpGet]
    public string DoGetAction()
    {
         // do something
         return string.empty;
    }
    

Thanks for reading. Hope you find this helpful!

Dec 18, 2017

Comments

Jan 29, 2018 12:59 PM

It does not work for me - episerver does not have the same logged in context. What else do you have in web.config and in OWIN startup file?

Please login to comment.
Latest blogs
Optimizely CMS platform bug in ErrorsController (EPiServer.CMS.Core 12.22.9 fix)

While checking  Application Insights earlier this year, I stumbled upon a strange exception in my Optimizely site. At first, I thought it might be ...

David Drouin-Prince | Nov 9, 2025 |

Avoid Using OnStatusChanged in Optimizely CMS – It Can Impact Database Performance

Beware of Overusing OnStatusChanged in Optimizely CMS Scheduled Jobs Optimizely CMS allows you to create scheduled jobs — a powerful feature often...

David Drouin-Prince | Nov 9, 2025 |

Optimizely CMS - Learning by Doing: EP06 - Create Header, Footer, Menu & Component/View for Blocks

  Episode 6  is Live!! The latest installment of my  Learning by Doing: Build Series  on  Optimizely CMS 12  is now available on YouTube! This vide...

Ratish | Nov 4, 2025 |

Going Headless: 3 Ways to Store Custom Data in Optimizely Graph

Welcome to another installment of my  Going Headless  series. Previously, we covered: Going Headless: Making the Right Architectural Choices Going...

Michał Mitas | Nov 3, 2025

A day in the life of an Optimizely OMVP - What's New in Optimizely CMS: A Comprehensive Recap of 2025 Updates

Hello and welcome to another instalment of a day in the life of an Optimizely OMVP. On the back of the presentation I gave in the October 2025 happ...

Graham Carr | Nov 3, 2025

Optimizely CMS Mixed Auth - Okta + ASP.NET Identity

Configuring mixed authentication and authorization in Optimizely CMS using Okta and ASP.NET Identity.

Damian Smutek | Oct 27, 2025 |