ServiceStack and IdentityServer4 "InternalServerError"

Good day,

I have been following these docs:

What I have is a simple Identity4 server (separate project) running on my local machine. It generates tokens and everything seems to work according to spec. Now when I add the [Authenticate] attribute to my requests I get the expected “401 Unauthorized”.

I am just trying to protect a service stack API so I just added the bottom part from the docs under the headline “API”.

So add the authentication “Bearer” to the services, add the Plugins “NetCoreIdentityAuthProvider” and the [Authenticate] attribute. Now I’m starting a request in Insomnia pointing to the previously working resource; add OAuth verification and I only get Unauthorized errors.

I have already checked the request (with the prerequestfilter) to see that the “Authorization” header is in the request with the value: “Bearer andalongtokenhere”.

Still unauthorized, I’m also not getting any further debug info. Can someone please help me get this working? Or help me get more info on this?

I feel like I’m missing something but I can’t figure it out.

Ps. I tried the default project: just to see if it works but after download it instantly reports some errors (Startup is not extended from ModularStartup etc) so it seems that project is broken by default.

The template shouldn’t use ModularStartup which I’ve resolved in this commit which is available the next time you create a new project, e.g:

$ x new mvcidentityserver ProjectName

The template should just work after running the 3 host projects, i.e:

  1. IdentityServer (https://localhost:5000/)
  2. MyApp (https://localhost:5002/)
  3. MyApp.Api (https://localhost:5001/)

Where you should be able to view your Web App (https://localhost:5001/) and Sign In. But there appears to be issues in the latest version with the IdentityServer integration when signing in, I’ll investigate why & report back tomorrow.

ok this issue is due to Chrome’s SameSite Cookie policy on newer browsers, explained in more detail with how IdentityServer is affected here:


Where the mvcidentityserver template works as expected if you disable the Chrome’s SameSite Cookie Policy:

Or if you use a different browser (like Firefox) or an older Chrome <80 browser that doesn’t have it enabled by default.

I’ve updated the template to use the documented workaround & changed to use https in this commit.

New templates should now start with a working configuration:

$ x new mvcidentityserver ProjectName

Thanks alot for your reply, this doesn’t seem to be the case with us though. A collegue of mine made this repo as an example:

When you request the /hello/mythz route on the API it works perfectly, when you request the servicestack-identity resource (with the correct Bearer header) it shows all kinds of stuff. However we implement it it shows either: a servicestack login page, a 404 not found and even a 405.

Whatever we try, we can’t get it to work with a simple client_id / secret token call.

You’ll need to start from this working project template as it’s the only starting configuration & integration scenarios with IdentityServer we’re supporting which I’ve retested with the latest changes using the latest version of Chrome and was able to confirm it to be working as expected again. I can investigate if there’s an issue with functionality in this Template.

Which API from the template is not working as expected?

Well it’s pretty simple; the Github project is a very easy demo that just doesn’t work. I’ve tried following all your docs to the letter but it just doesn’t work.

We have decided to stop using servicestack all together. It’s a very sad conclusion but I just won’t work in the simple way that it should. We’ll soon be removing it from all our projects for this very reason sadly.

Ps. I don’t think you can expect everybody to start working from your template. You should just be able to drop in some IdentityServer / Oauth / Opic logic without to much hassle. As you can do with the default MVC templates within 5 minutes.

The solution eventually was using IdentityServer4 in a servicestack host. Not the solution we hoped, but it’s the only way we could make it work in the end.