locked
Identity Server setup for trusted apps RRS feed

  • Question

  • User1358036820 posted

    I am new to IDSVR and wish to set up in the following way.

    I have some apps that are trusted like an MVC app and Frontend app, Mobile etc.  All these are inhouse developed.

    I wish to set up login using native interface for user/pass auth.  I don't wish to use the redirect here and would probably have idenityserver work behind the scenes without exposing it to outside (for now at least).

    My thinking for now is as follows

    Host idSvr in its own project and run on server

    Have an api talk to idSrv internally in terms or authorization/authentication and return result like tokens back to the app calling the api

    Questions

    1) When using MVC client that calls my API and retrieves tokens, do I just create a cookie from the mvc app to store the token?

    2) If I do it above way, will this open up any security issues?

    Again my aim is to just have a native login interface that talks to idenityserver so my users can sign in at mydomain.com/login rather than redirected to idSvr and having to maintain the UI for that as well.

    Thursday, June 20, 2019 3:51 PM

All replies

  • User475983607 posted

    ammd

    I am new to IDSVR and wish to set up in the following way.

    I have some apps that are trusted like an MVC app and Frontend app, Mobile etc.  All these are inhouse developed.

    I wish to set up login using native interface for user/pass auth.  I don't wish to use the redirect here and would probably have idenityserver work behind the scenes without exposing it to outside (for now at least).

    My thinking for now is as follows

    Host idSvr in its own project and run on server

    Have an api talk to idSrv internally in terms or authorization/authentication and return result like tokens back to the app calling the api

    Questions

    1) When using MVC client that calls my API and retrieves tokens, do I just create a cookie from the mvc app to store the token?

    2) If I do it above way, will this open up any security issues?

    Again my aim is to just have a native login interface that talks to idenityserver so my users can sign in at mydomain.com/login rather than redirected to idSvr and having to maintain the UI for that as well.

    The main problem a central token server solves is removing user credentials from a secured application.  If you plan to proxy user credentials from your app to Identity Server, then you should use ASP.NET Identity rather than Identity Server.  Identity Server stores a cookie on the client browser after a successful login.  This part will be missing form your design which will affect SSO.

    I use Identity Server and as far as I know there's no configuration that meets your requirement when it comes to user logins.  The best you can do is register applications not specific users. 

    Thursday, June 20, 2019 4:03 PM
  • User1358036820 posted

    I appreciate your answer, and think you might be right, there does not seem to be an easier way apart from maybe proxying the cookie created by the auth server.  My whole aim is that I really don't want my users to go somewhere like login.mydomain.com and really want them to stay on mydomain.com/login.  Its more about having as one project then to have splits projects like auth server, api,app all running under different domains/sub-domains.

    Thursday, June 20, 2019 4:15 PM
  • User475983607 posted

    I appreciate your answer, and think you might be right, there does not seem to be an easier way apart from maybe proxying the cookie created by the auth server.  My whole aim is that I really don't want my users to go somewhere like login.mydomain.com and really want them to stay on mydomain.com/login.  Its more about having as one project then to have splits projects like auth server, api,app all running under different domains/sub-domains.

    Identity Server does not meet your requirement.  ASP.NET Identity does though.

    Also proxying the Identity Server cookie will not work in a browser based application.  You'll proxy the credentials not a cookie.  Basically forward the username and password to an endpoint on Identity Server essentially turning Identity Server into a login service not a token server.

    Thursday, June 20, 2019 4:34 PM
  • User1358036820 posted

    So you are saying use identity for the mvc app and use ResourceOwner flow for trusted mobile/windows apps?

    Thursday, June 20, 2019 9:38 PM
  • User475983607 posted

    So you are saying use identity for the mvc app and use ResourceOwner flow for trusted mobile/windows apps?

    Not exactly.  You want to use Identity Server but not redirect clients to login.   That means you are not planning to take advantage of OAuth/OIDC and that fine. 

    The spec generally recommends against using the resource owner password grant besides legacy applications that cannot host a browser. Generally speaking you are typically far better off using one of the interactive OpenID Connect flows when you want to authenticate a user and request access tokens.

    I use Identity Server and I'm a fan.  But, if I only needed the resource owner grant then I would roll my own with Identity.  If I need the resource owner grant now but in the future need OAuth/OIDC then I would go with Identity server.

    Friday, June 21, 2019 11:40 AM