Twitter API Question posted in
The official Twitter API documentation can be found here.

Microsoft Identtiy & Identity Server 4 process flow relationships – Twitter API

I’m working on building a series of micro-services using Aspnet Core. A mobile application, desktop application and web-application will consume the services over Http REST APIs.

For user auth, I’m utilizing the Aspnet Core Identity platform, but I’m exposing the creation of user accounts via a REST API. The clients make a REST call with the credential information and my API uses the Microsoft Identity APIs to provision the user. The user would be authorized to hit the individual resource servers with an auth server using IdentityServer4.

I have two questions that I’ve not been able to find clear guidance on from a security stand-point. Should the Aspnet Core project that utilizes Microsoft Identity for user creation be in an independent Aspnet Core project from the project that handles auth via IdentityServer4? Are there downsides do separating the two out that I need to consider?

The Microsoft Identity API has template and Razor Views that can be used to handle the auth from a server-side perspective, including redirects on account creation or sign-in etc. If I’m doing everything via SPA or Client-side native apps, is there anything wrong with just providing a POST API that accepts the user information, creates the account via UserManager<T> and returns the UserId?

I want to provide a dedicated sign-in page, similar to FB/Google/Twitter etc for Auth to happen across any app that wants to authorize a user for my services. I don’t typically see account creation as part of the OAuth process though. Is it typical that you would allow for redirects to an account creation page, that redirects back to a client upon successful account creation or is that process typically just used for Auth via OAuth flows?

Tags:

2

Answers


  1. 0

    I would suggest to consider using one service for IDS4 and ASP.NET Identity since they can be integrated and give you the full functionality you’re looking for(auth, and users management).

    IDS4 has examples and good documentations regarding that.

    To me, I think separating them would be an over engineering.

    one example: when IDS4 generate access token for a user, you should get claims, roles and validate username and password, all of that are stored in ASP.NET Identity.

    So for more details you can check the docs of Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html

    or it’s my pleasure to check my little blog post that I tried to give some more detailed and step by step.
    https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/

    Start with IDS4 link because it might be enough 🙂

    Login or Signup to reply.
  2. 0

    The main point when thinking about security management UI is how to secure that UI. And the most safe approach for today is cookie-based auth with same-site cookie (the way, MVC uses by default). Consider that when and if selecting serverless SPA pattern. For management purposes-app having strict backend is much more secure than token-based access to distributed api-s.

    Regarding the application hosting, @VidmantasBlazevicius is absolutely right, there is no the only strategy: hosting all the services in one app is simpler, so it better fit lo to middle loaded systems. But with raise of the number of users and authentication requests, you might want to scale, and separating management UI from authentication is one of the ways to handle that.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search