title: WebApi authentication with owin and LinkedIn auth provider under Asp.Net
body: <p>We have a webApi running under Asp.Net with Owin (.Net Framework 4.6).
  Several native frontend clients (iOs, android etc.) are using that api.
  That API currently uses Microsoft Login with bearer token and cookie authentication. This works, and the access token is returned directly to the webView in the client with the redirected requests and we are able to access our API with the Bearer token and another authentication cookie.
  We have now the task to implement authentication with a LinkedIn auth provider in that API. For clearification: we need an <strong>OWIN</strong> implementation (no AspNet.Core).</p>
  
  <p>We are able to get the access token from LinkedIn within the webAPI using this <a href="https://github.com/TerribleDev/OwinOAuthProviders/tree/master/src/Owin.Security.Providers.LinkedIn" rel="nofollow noreferrer">LinkedIn auth provider</a>. So we see the token in our User.Identity.Claims. We are also able to return it to the client again. Yes, this is maybe no good idea, but it seems to be not possible to get the token directly in the browser/webView because the response_type=code is mandatory for linkedIn authentication. With response_type=token this works for the microsoft authentication.</p>
  
  <p>Anyway at the end the webview is redirected to following url though we already have retrieved the access_token:
  <a href="http://10.0.2.2:8108/signin-linkedin" rel="nofollow noreferrer">http://10.0.2.2:8108/signin-linkedin</a>?<strong>error=unsupported_response_type</strong></p>
  
  <p>Please just ignore that we do not use https for now. The host is only for testing, but the important part is the appended error.</p>
  
  <p><strong>Why do we get this error? Who calls this request and why do we have that error though we have the token already?</strong> </p>
  
  <p>Another information is, that the access token we have now in the client cannot be used for authentication against the webAPI. So we get back a 401 Unauthorized.</p>
  
  <p>Maybe I should mention explicitly that we use also cookie authentication in the api, which seems to work as we receive the cookie in the webView and we are able to call methods that are protected with cookie authentication only in the correct user context. </p>
  
  <p>Any help is highly appreciated!</p>