single-sign-onidentityserver4

Login to multiple Apps with IdentityServer4


I have to develop a SSO system and I have to do it using IdentityServer4. I have gone through the documentation and examples but I have some doubts. To be honest I don't quite get it, but I am really new in Oauth2 and OpenId Connect.

We will have a bunch of clients (web apps), each of one of those will have their own Web API. And we have to have a centralized Login App for all of those. I think the example with the JavaScript client is the closest to the thing we want to achieve. Also, a user might have permission to access one client (app), but not another, so the IdentityServer must provide information about which clients (apps), that particularly user can access.

So, These are the things I don't Understand:

  1. In the documentation I can read there are two tokens, an Identity Token and Access token. But in the examples all I see are the access tokens. It seems to me that the access token is the one with all de info needed. am I wrong?

  2. Also, I have read about de Grant Types and I am not quite sure which one we must use. At first I thought to use the ResourceOwner password, because it requires the client, the secret, a user and a password, which I assumed it could be the end user. I found this example http://sunilrav.com/post/How-to-Customize-Authentication-in-Identity-Server-4 were one could customize the class that validate the user and password. I thought that this could be the way to go but the documentation statesa about this grant type "...This is so called “non-interactive” authentication and is generally not recommended.". The JavaScript client example uses the implicit Grat type, which the documentation states is for browser-based applications (our client apps will all be browser based using react).

  3. can my Login app be a JavaScript (react) app? The example Quickstart is made in MVC.NET. This login app connects directly to de IS4 server without asking for a access token? (In the example the app is embedded in the IS4).

  4. Can I protect with IS4 a WEB API which is developed in .net framework (4.6.2) and not in .Net Core? I haven't Found Any examples.

the documentation I followed is the official. The examples (quickstart) are also there. (I can't post more than two links).

thank you very much for reading and for your help.


Solution

  • Identity Token and Access token Identity token is the one that contains the identity of the user, that will tell the client app that what user it is. After successful login, user will be redirected to the client app with these tokens. Response will also have claims, such as permission scopes, name , email you can add custom claims as well.

    Access token is used to access your protected web api resource. You have to send the access token with each request to access the api.

    Grant Types Grant types is basically how you want your client app to interact with the auth server. https://identityserver4.readthedocs.io/en/release/topics/grant_types.html

    can my Login app be a Javascript (react) app? Your client app can be a javascript app but your auth server that is the identity server which will have the login/signup pages(and other login jazz) and account controllers should be you MVC app. As, everything is already done using MVC and Entity framework, why you want to re do everything.

    Can I protect with IS4 a WEB API I am not sure about this one, but I dont see why you would not be able to do it.

    This is a good answer for basic IdSrv flow!

    UPDATE In my understanding, the answer to which Grant Type to use it depends on your client application requirement. If you want to use a Javascript client you can use Implicit Flow, but you won't be able to use refresh tokens and your access token is not 100% secured with the browser as client can access it.

    If you want to open your web api to public then you can use client credentials flow. If you want to be more secure you should use Hybrid flow or HybridClient credential flow. ( again depends on the requirements ). with this you will be able to use refresh tokens and in this way your access token would be more secure.