title: IdentityServer4 personal access token (github-like) or API key for third party clients
body: <p>Our current setup is</p>
  
  <ul>
  <li>IdentityServer4 </li>
  <li>Angular + ASP.NET Core application</li>
  <li>Authentication for the app via implicit flow/oidc.</li>
  </ul>
  
  <p>We want to provide APIs for customers, i.e. third party clients, with restricted access (separate set/subset of claims). These clients are mostly non-interactive scripts that download data.</p>
  
  <p>This means that we cannot use any flow which (occasionally) requires user interaction. Personal access tokens, like in github, or some other <em>generate once, reuse for a long time</em> API key or token would be needed.</p>
  
  <p>The long token lifetime would not be a security issue, because the token should only allow access to a few read-only APIs and only for that customer's data - so the responsibility to handle the token(s) falls onto the customer.</p>
  
  <p>The customer should be able to create and revoke such API-access tokens based on their claims. Some users might only claims to access certain APIs.</p>
  
  <p><em>It would be good if we could later prevent that the user re-uses the same token for multiple clients because of licensing requirements but that is perhaps an entirely new question</em></p>
  
  <p><strong>How could I achieve this?</strong></p>
  
  <p>I thought about doing this via a custom grant, similar to a <em>delegation grant</em>: user uses app, which calls the asp.net core API, which performs auth with that custom grant, persists that token somewhere (just a plain table in the database full of customer-api-only tokens? I'm not sure about that) and shows it to the user - which can also retrieve it later from storage.</p>
  
  <p>I'm thinking about doing the "delegate"-authentication via our API so that we don't leak the secrets into the Angular application.</p>
  
  <p>I think that we then should be able to have either long-lived access tokens or at least refresh tokens via that custom grant.</p>
  
  <h1>2017-12-12 how I think I could solve it</h1>
  
  <p>We want a process where the user generates <em>something</em> in our application (i.e. via our client) and this <em>something</em> can later be used by the user's third party client to access the API - or request an access token and then access the API.</p>
  
  <p>We want this access to be tied to the user. This includes
   - Disabled user
   - Lockout
   - Specific claims (e.g. tenant)</p>
  
  <p>This does not lend itself well to a solution that issues access tokens directly, because the token would remain valid even if the user was disabled or locked out. Which means that we cannot use a custom grant or <code>IdentityServerTools</code> to issue tokens directly.</p>
  
  <p>Therefore we should use the client credentials grant, or something similar to it, as this could yield new, short-lived access tokens.</p>
  
  <ul>
  <li>User actually generates a new client, which is pre-filled with claims from  the user (such as the tenant - which is immutable) and has a claim that corresponds with the user. This happens transparently. Password should be user-supplied with the option to change it. We only store the relation between user and issued client-ids, no passwords.</li>
  <li>We have to create a custom grant, which works similar to client credentials, but also checks if the corresponding user is active etc. (which I think should be possible by injecting <code>UserManager</code>)</li>
  <li>Resulting access token lifetime is short, interaction with our APIs is expected to be short-lived.</li>
  </ul>
  
  <p>Assuming it is safe and easy enough to write such a grant, we should be able to cover everything we need.
  Of course, I might have completely overlooked something :)</p>