4

Which one of these would be the easiest to setup server-to-server JWT on? I already have an existing JWT token do I need to setup an entire server just to pass through the token?

I have a requirement use-case to create a client for a web API hosted on another server but cannot figure out how to pass the credentials in .NET Core to the other server, I just need to be able to construct a GET and a POST using C# into a remote server API and build some charting to display the results of the GET.

Fred
  • 12,086
  • 7
  • 60
  • 83
webdev8183
  • 153
  • 2
  • 4
  • 16
  • You already have a jwt token? Where from, and why can't you use the authority that provided that token to verify it when you want to use it in your web-api? Identity Server is straight-forward to set up, and hook into your own identity providers, and has middleware that can be used by your protected resources to verify integrity - if that's what you need. – Mashton Mar 05 '17 at 21:59
  • I don't really need auth built into this as I won't be servicing clients, I am the client.. , my question is how do I pass the token to my request, which in .net core does not seem straightforward at all to me, I don't get a new token, I don't have a login to the remote, I can send request using postman just fine, but something as simple as adding a header to a post or get, should be easier to find in the documentation, hooray for dependency injection and all, but really it sometimes makes things way more difficult than they need to be. – webdev8183 Mar 05 '17 at 23:44
  • 7
    @johnny5 saying "Identity Server 4 is the biggest pain ever" without even presenting your arguments sounds *a bit* harsh, IMHO. Since IdSrv is a free OSS project, why not contacting the project owners to tell them how the "pain points" could be reworked? – Kévin Chalet Mar 05 '17 at 23:51
  • @webdev8183 please see this question I've asked (http://stackoverflow.com/q/42121854/1938988) – johnny 5 Mar 06 '17 at 00:07

3 Answers3

2

If you're gong to be using .Net 6, you need to consider the pricing model of Identity Server 5.

As Identity Server 4 which is free, does not support .Net 6.

The license for Identity Server 5 is only free for non commerical projects and commercial projects if you make under 1 million dollars revenue. And it seems in the license if you make under that, you can only use it freely for 1 year.

This is a big advantage for OpenIddict as it's free.

Identity Server 5 pricing

Dylan
  • 1,071
  • 1
  • 12
  • 24
1

You can set a cookie then redirect to a subdomain. The benefit of this method is that it prevents XSRF/session fixation attacks as pointed out by Pinpiont. The disadvantage is that both sites have to reside on the some domain.

    [RequireHttps]
    public IActionResult Redirect()
    {
        var token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
        const string domain = "subdomain.example.com";

        Response.Cookies.Append("token", token, new CookieOptions {
            Domain = domain,
            Expires = DateTime.Now.AddHours(1),
            HttpOnly = true,
            Path = new PathString("/Account"),
            Secure = true,
        });

        return Redirect($"https://{domain}/Account");
    }
Fred
  • 12,086
  • 7
  • 60
  • 83
-2

If you already have a token then you don't need IdentityServer4 or OpenIddict. IdentityServer4 and OpenIddict issues tokens upon request, but you seem to already have issued them yourself locally.

I sent my token from Site A to Site B using a form that does a POST over HTTPS.

<form action="https://other-server.example.com/Account/" method="post" id="form">
  <input name="token" type="hidden" value="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...">
</form>

You can also automatically submit the form using JavaScript.

<script>
  document.getElementById('form').submit();
</script>
Fred
  • 12,086
  • 7
  • 60
  • 83
  • 2
    One of the positive aspects of implementing standard protocols like OAuth2 or OpenID Connect is that the threat model is generally well known. Your homemade protocol is unfortunately vulnerable to XSRF/session fixation attacks, as nothing prevents me, as a bad guy, from creating an HTML auto-post form pointing to `https://other-server.example.com/Account/` and sending one of my own tokens. If a victim visits my malicious page, he will be automatically logged in under my own account, potentially leading to a data leakage if the victim sends personal data to your website. – Kévin Chalet Sep 29 '17 at 05:19
  • @Pinpoint Thank you very much for your comment. That is a very valid point which I had not taken that into consideration. I guess that could be mitigated by checking the HTTP Referer header to make sure it originates from a trusted origin. Either way, I would love for you to post a answer with your suggested solution to the question. – Fred Oct 01 '17 at 22:15