Implement identity server authentication in real world scenario

Raskolnikov picture Raskolnikov · Jan 14, 2016 · Viewed 13.8k times · Source

I am investigating how IdentityServer 3 works and I still have problem to fully understand.

In general concept is clear to me but still I am not sure how to implement this on real project.

This is basic example that I am trying to implement in my case: link

I have web api project and I want to call my api methods from any client (mvc, wpf, phone…) So I need implementation that is suitable for all clients.

If I understand well (and probably I am not understand completely), I should have 3 projects:

  • Client
  • Api
  • Project that host IdentityServer

And all projects should have required stuff like on picture: enter image description here Steps on picture:

  1. Get token
  2. Return token
  3. Call api
  4. Check if Token is OK
  5. If Token is fine than return data else show error

My questions are:

  • Is my thinking about how this works ok?
  • Where I making mistakes?
  • Is this example good enough for my case? Am I missing something important?
  • Do I have to create project that host IdentityServer, or this is needed just for example code ?
  • Does IdentityServer host project must be console application that communicate with api and client(like in example), or in real world this is done differently ?
  • Should project that host identity server be aware of Clients and Users ?
  • Should some other project except host identity server project be aware of Clients and Users ?
  • What is diference between implicit and hybrid flow, what I need in my case and why?
  • How do I create my own login view? I want have html page for login if I use web client, but to have wpf login view if I use wpf, also different view for mobile client.

EDIT: I think that I need Resource Owner flow . I supose that resource i view where user type user name and password.

Answer

Scott Brady picture Scott Brady · Jan 15, 2016

Your basic flow is correct, with Identity Server acting as your authorization server and your client and web API separate.

You should host Identity Server in its own project to ensure it is separate from any other logic which has the potential to introduce security concerns. How you host it is up to you and your use case. Typically you would see it hosted within an ASP.NET project on an IIS Server.

Identity Server must be aware of clients and users in order to authenticate them. The only other projects that should be aware of your identity store (users) is any applications that concern things like admin, user registration, etc. The client store would only ever be used by Identity Server.

Views can be modified using the Identity Server templates or by introducing your own ViewService. See the docs for more info: https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html

Regarding flows, the Resource Owner flow is OAuth only, so there will be no authentication (log in page), only authorization (server to server).