IdentityServer4 with ASP.Net Identity Project Architecture
up vote
0
down vote
favorite
I'm working on RESTful API that implements OpenID and Oauth2. IdentityServer4 offers both and works perfectly, however nearly all examples and tutorials use in memory Test Users
I've been struggling to understand how I can implement IdentityServer4 with database while having some sort of a services that allows users accounts to be created and managed.
I'm confused whether the registration and account management services should take place on IdentityServer4 itself or somewhere else, on a different project.
I've been trying to glue together IdentityServer4 with ASP.NET Identity in a single project, however I have no idea whether this approach is correct or not.
How would architecture that implements IdentityServer4 and ASP.Net Identity look like? Should I create 2 separate projects, one for IdentityServer4 and the other for ASP.Net Identity, or should I try combining both?
asp.net identityserver4
add a comment |
up vote
0
down vote
favorite
I'm working on RESTful API that implements OpenID and Oauth2. IdentityServer4 offers both and works perfectly, however nearly all examples and tutorials use in memory Test Users
I've been struggling to understand how I can implement IdentityServer4 with database while having some sort of a services that allows users accounts to be created and managed.
I'm confused whether the registration and account management services should take place on IdentityServer4 itself or somewhere else, on a different project.
I've been trying to glue together IdentityServer4 with ASP.NET Identity in a single project, however I have no idea whether this approach is correct or not.
How would architecture that implements IdentityServer4 and ASP.Net Identity look like? Should I create 2 separate projects, one for IdentityServer4 and the other for ASP.Net Identity, or should I try combining both?
asp.net identityserver4
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm working on RESTful API that implements OpenID and Oauth2. IdentityServer4 offers both and works perfectly, however nearly all examples and tutorials use in memory Test Users
I've been struggling to understand how I can implement IdentityServer4 with database while having some sort of a services that allows users accounts to be created and managed.
I'm confused whether the registration and account management services should take place on IdentityServer4 itself or somewhere else, on a different project.
I've been trying to glue together IdentityServer4 with ASP.NET Identity in a single project, however I have no idea whether this approach is correct or not.
How would architecture that implements IdentityServer4 and ASP.Net Identity look like? Should I create 2 separate projects, one for IdentityServer4 and the other for ASP.Net Identity, or should I try combining both?
asp.net identityserver4
I'm working on RESTful API that implements OpenID and Oauth2. IdentityServer4 offers both and works perfectly, however nearly all examples and tutorials use in memory Test Users
I've been struggling to understand how I can implement IdentityServer4 with database while having some sort of a services that allows users accounts to be created and managed.
I'm confused whether the registration and account management services should take place on IdentityServer4 itself or somewhere else, on a different project.
I've been trying to glue together IdentityServer4 with ASP.NET Identity in a single project, however I have no idea whether this approach is correct or not.
How would architecture that implements IdentityServer4 and ASP.Net Identity look like? Should I create 2 separate projects, one for IdentityServer4 and the other for ASP.Net Identity, or should I try combining both?
asp.net identityserver4
asp.net identityserver4
asked Nov 22 at 16:15
OverflowStack
218515
218515
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
It really boils down to what your requirements are. ASP.Net Identity implements a lot of boilerplate stuff and is good for getting you up and running quickly and it integrates well with IDS4. We used it in our implementation but ended up customizing it a LOT so I'd suggest if your requirements differ significantly from what it provides out of the box it may be more of a pain in the long term to have that additional dependency.
In my opinion it makes sense to treat your identity server as a self contained (micro) service that owns its own data (users, clients, persisted grants etc) and exposes any needed APIs for managing said entities from outside. IDS4 does not stipulate or particularly care how you do user authentication or how you store the data so you're free to implement that any way you like.
Do you have a preference when it comes to database? How will it be deployed?
I'm currently doing researching and trying to understand the best practices with Identity Server. Not really any requirement other than being able to secure API, working with multiple flows and implemention of different access rights. What I am confused about is where I should do the user management with ASP.Net Identity - on Identity Server itself (that is how I am doing it now) or separate, isolated project.
– OverflowStack
Nov 23 at 10:19
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
It really boils down to what your requirements are. ASP.Net Identity implements a lot of boilerplate stuff and is good for getting you up and running quickly and it integrates well with IDS4. We used it in our implementation but ended up customizing it a LOT so I'd suggest if your requirements differ significantly from what it provides out of the box it may be more of a pain in the long term to have that additional dependency.
In my opinion it makes sense to treat your identity server as a self contained (micro) service that owns its own data (users, clients, persisted grants etc) and exposes any needed APIs for managing said entities from outside. IDS4 does not stipulate or particularly care how you do user authentication or how you store the data so you're free to implement that any way you like.
Do you have a preference when it comes to database? How will it be deployed?
I'm currently doing researching and trying to understand the best practices with Identity Server. Not really any requirement other than being able to secure API, working with multiple flows and implemention of different access rights. What I am confused about is where I should do the user management with ASP.Net Identity - on Identity Server itself (that is how I am doing it now) or separate, isolated project.
– OverflowStack
Nov 23 at 10:19
add a comment |
up vote
2
down vote
accepted
It really boils down to what your requirements are. ASP.Net Identity implements a lot of boilerplate stuff and is good for getting you up and running quickly and it integrates well with IDS4. We used it in our implementation but ended up customizing it a LOT so I'd suggest if your requirements differ significantly from what it provides out of the box it may be more of a pain in the long term to have that additional dependency.
In my opinion it makes sense to treat your identity server as a self contained (micro) service that owns its own data (users, clients, persisted grants etc) and exposes any needed APIs for managing said entities from outside. IDS4 does not stipulate or particularly care how you do user authentication or how you store the data so you're free to implement that any way you like.
Do you have a preference when it comes to database? How will it be deployed?
I'm currently doing researching and trying to understand the best practices with Identity Server. Not really any requirement other than being able to secure API, working with multiple flows and implemention of different access rights. What I am confused about is where I should do the user management with ASP.Net Identity - on Identity Server itself (that is how I am doing it now) or separate, isolated project.
– OverflowStack
Nov 23 at 10:19
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
It really boils down to what your requirements are. ASP.Net Identity implements a lot of boilerplate stuff and is good for getting you up and running quickly and it integrates well with IDS4. We used it in our implementation but ended up customizing it a LOT so I'd suggest if your requirements differ significantly from what it provides out of the box it may be more of a pain in the long term to have that additional dependency.
In my opinion it makes sense to treat your identity server as a self contained (micro) service that owns its own data (users, clients, persisted grants etc) and exposes any needed APIs for managing said entities from outside. IDS4 does not stipulate or particularly care how you do user authentication or how you store the data so you're free to implement that any way you like.
Do you have a preference when it comes to database? How will it be deployed?
It really boils down to what your requirements are. ASP.Net Identity implements a lot of boilerplate stuff and is good for getting you up and running quickly and it integrates well with IDS4. We used it in our implementation but ended up customizing it a LOT so I'd suggest if your requirements differ significantly from what it provides out of the box it may be more of a pain in the long term to have that additional dependency.
In my opinion it makes sense to treat your identity server as a self contained (micro) service that owns its own data (users, clients, persisted grants etc) and exposes any needed APIs for managing said entities from outside. IDS4 does not stipulate or particularly care how you do user authentication or how you store the data so you're free to implement that any way you like.
Do you have a preference when it comes to database? How will it be deployed?
answered Nov 23 at 9:30
mackie
1,8731110
1,8731110
I'm currently doing researching and trying to understand the best practices with Identity Server. Not really any requirement other than being able to secure API, working with multiple flows and implemention of different access rights. What I am confused about is where I should do the user management with ASP.Net Identity - on Identity Server itself (that is how I am doing it now) or separate, isolated project.
– OverflowStack
Nov 23 at 10:19
add a comment |
I'm currently doing researching and trying to understand the best practices with Identity Server. Not really any requirement other than being able to secure API, working with multiple flows and implemention of different access rights. What I am confused about is where I should do the user management with ASP.Net Identity - on Identity Server itself (that is how I am doing it now) or separate, isolated project.
– OverflowStack
Nov 23 at 10:19
I'm currently doing researching and trying to understand the best practices with Identity Server. Not really any requirement other than being able to secure API, working with multiple flows and implemention of different access rights. What I am confused about is where I should do the user management with ASP.Net Identity - on Identity Server itself (that is how I am doing it now) or separate, isolated project.
– OverflowStack
Nov 23 at 10:19
I'm currently doing researching and trying to understand the best practices with Identity Server. Not really any requirement other than being able to secure API, working with multiple flows and implemention of different access rights. What I am confused about is where I should do the user management with ASP.Net Identity - on Identity Server itself (that is how I am doing it now) or separate, isolated project.
– OverflowStack
Nov 23 at 10:19
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434841%2fidentityserver4-with-asp-net-identity-project-architecture%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown