Implement identity server authentication in real world scenario

Question

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: 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.

Pharos

Answer 1

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).

Anticline

Thanks for answer. Regarding login page it is still not clear to me. I plan to have many clients for same API. I will have MVC web client, WPF windows client and probably other clients. So I need to have login page on every client. It does not make sense to login trough browser if client is WPF or phone. That’s why I want to use Resource owner flow. To send user and password from client (whatever that client is). Does this make sense or I should use different approach? – Pharos

So I dont know what you want to say with " there will be no authentication" ? It will be authentication because with Resource Owner flow you have to send user name and password. Just this user name and pasword will be provided from client and not from identity server. Am I right? – Pharos

You'll want to authenticate each one of your clients using an OpenID Connect flow that will allow you sign in your users and then grab an access token to your web API (e.g. the hybrid flow). This token can then be used to authorize access to the web API using an OAuth flow such as client credentials or resource owner. – Anticline