title: Right architecture for Authentication and Authorization with IdentityServer4
body: <p>I'm trying to implement the right architecture with authentication on IdentityServer4 (IS4).
  So I will have a server that does as identity provider with oidc and oauth2 tokens for SSO and access tokens to protect the web api. User profiles will be stored in the IS4 database.
  I have many applications that will refer to the IS4, but let's think about just one application for an easy scenario.</p>
  <p>I read a few article about the difference between authentication and authorization, and if I correctly understood, it's not a good idea to store authorization info in claims or with other tricks in IS4. It should manage only the identity of the user and it's attributes but NOT the permissions it has in other applications.</p>
  <p>So, my doubt is about the management of permissions... about authorization.
  Does every application know all the users, matching by id to the IS4 representation, to manage the specific permission? This means that I have to sync every application DB with the IS4 DB!
  Is it preferable to implement a service for authorization management that stores the rules that are not retrievable from the claims?</p>
  <p>This is an example of the problem:</p>
  <ul>
  <li>The user John is a &quot;standard user&quot;. I see it in the claims. I can have the information about his generic role.</li>
  <li>Because John is not an &quot;administrator&quot; he cannot access the print and setup menus in the application.</li>
  <li>I would like to dynamically add the authorization to access the print menu to john, but NOT the setup menu.</li>
  </ul>
  <p>Since John will maintain the role of &quot;standard user&quot; I think I must store the info of &quot;show print menu&quot; permission in the specific application.</p>
  <p>Is my vision of the architecture correct or is there a better way to implement the scenario?</p>