I just integrated the MembershipReboot to my Thinktecture Identity server V2. Now ,I would like to extend user profile like firstname, lastname, facebook, twitter, etc..
Is there any way that I can do it like in ASP.NET membership provider just need to modify config file only with MembershipReboot?
IIRC, the MR sample implements the IClaimsRepository interface -- this is the interface you need to implement to expose claims for the tokens issued from IdentityServer.
Related
I'd like to setup an integration with a third party vendor for which I have to provide services, which need to be customer-aware.
The main flow is on the third party, that already have a service provider and an identity provider; the third party service provider then have to call my service, but then I need to check the authentication, for which I would like to rely on their identity provider, gaining so also access to the user identity (name, mail, other data).
basic flow
Does a flow like this can work? Do I have to receive the authentication infos cookie? Are other ways for which I can integrate with the third party identity provider?
Current web standards would likely dictate OIDC, especially if you want your service to be open to direct consumers as opposed to, or in addition to enterprise users. Were I building something today, I would choose to build out only OIDC, because it doesn't limit the Identity Providers I may want to use. In addition to enterprise, you could consider social logins as well, such as Facebook, Google, etc. If your users are ONLY enterprise users, then yes, you could consider SAML.
The identity data is usually returned to you in a JSON Web Token, or JWT.
I would suggest looking at OIDC implementations on your favorite stack, or look to a cloud provider.
I have a need to implement Open ID Connect in an ASP.NET Core 5 web app for authentication at an organization. I cannot test against the identity provider as this org has their own internal one.
I thought Open ID Connect (oidc) was a standard - yet when I look at docs and sample code for the various providers around, they all either have something provided with ASP.NET or I have to install their package.
For example, to use Google, the ASP.NET Core docs say to use services.AddAuthentication().AddGoogle(). For Facebook, it says to use .AddFacebook().
For Auth0, it wants me to install the package Auth0.AspNetCore.Authentication.
Is it not possible to just add OIDC authentication to my app and have it work with any OIDC provider and just change a configuration file to specify the authority URL, Client ID, Client Secret?
I'm confused about why I need these provider-specific calls and packages.
Architecturally, tieing an app to a single form of authentication is entirely wrong, as you suggest. These packages have limited use, perhaps for very simple use cases.
The original OAuth 2.0 spec from RFC6749, from 2012, describes how the OAuth framework is designed, to externalize difficult security from your apps:
The client only implements a code flow
It redirects to an authorization server (AS)
The AS can authenticate users in a myriad of potential ways, including many identity providers
After authentication (and possibly consent) the AS issues tokens to your apps
Tokens enable authorization in your APIs in a myriad of potential ways
Once you've implemented a code flow in your app, your set of users can potentially login in many ways, with zero code changes in the app:
Password sign in (a default option)
Multi-factor authentication (in a dynamic way potentially)
Cloud platform identity providers (for engineering staff)
CRM identity provider (for client focused staff)
SAML identity providet (for users from business partners)
Webauthn, Passkeys and Digital wallets (for some of your customers)
Unless you have a very good reason, stick to OpenID Connect standards based code flows in clients. You can do all of the above using the Microsoft libraries. Auth0 have good libraries also - just make sure you use the standards based ones.
OpenID Connect is an open standard that organisations use to
authenticate users. IdPs use this so that users can sign in to the IdP
From this blog.
And about the OIDC protocol, it allows you to authenticate users, and is designed for users to sign in many websites with only one account, usually it's a social/work account. This is only a protocol and you have to use an implement such as Google/Azure authentication to allow your users to sign in with their specific account.
By the way, since the implements are from different companies, so the configuration in our codes are different and they required different nuget packages like Microsoft.Identity.Web. For example, when using Azure, we need to set such as client id, client secret, tenant id, domain, redirect url... in appsettings.json.
I'm writing a Blazor server application.
In this I would like to use my own user database and not that of Asp.Net Core Identity.
Does anyone have an example of this?
Or can I write a CustomUserManager?
I simply want a login with username and password that is validated in my own database.
The ASP.NET Core Identity is an API that supports user interface (UI) login functionality and helps to manage users, passwords, profile data, roles, claims, tokens, email confirmation, and more. And it is using the EF core to access data from database. If you want to use your own database, you could change the connection string to yours.
If you don't want to use Asp.net core Identity, you could create the Account or Role controller by yourself, and add the login page. Then refer the EF core tutorial to connect the database, and then manage users and roles or validate users.
The question: Should I use .Net Core Identity or IdentityServer 4 with Identity
I need to build app with login/register functionality and allow users to use APIs to import/export data from my software. I also want to have external logins like google, twitter, etc.
And I'm not able to understand why would I need Identity Server when all things can be done using only Identity.
Why would I need or want IdentityServer ? I just need to get work done right and as simple as possible.
You really can't compare the two.
ASP.NET Identity is a database API to manage users, roles, claims, email confirmation tokens etc. Something you can use for implementing signup, login, change password etc.
IdentityServer is an OpenID Connect and OAuth 2.0 implementation. It gives you features like single sign-on and API access control. This is useful if you want to share users between multiple client applications.
You can combine both though - use IdentityServer for the protocol work, and ASP.NET Identity for the user management on your central login page.
It depends.
IdentityServer will provide you with OAuth 2.0 and OpenID Connect implementation, and it will handle all details for you (providing you endpoints, token management, scopes, grants and so on). It runs independently so you can use it for multiple clients (SPA, mobile, web apps) and it is nicely isolated from rest of your app. If you wish so, you can use it together with ASP.NET Core Identity.
If you don't use IdentityServer, you will have to write some of these things yourself because ASP.NET Core Identity is a membership system and it does not provide any ready to use endpoints and neither token management or support for different ways how to authorize.
You need to evaluate whether it is better for you to write these things yourself but have a more straightforward setup because you probably don't need everything IdentityServer provides although it might limit you in future.
You can also have a look at OpenIddict that is less complicated than IdentityServer.
We currently have several web systems that are using the old Membership provider in silos. I am looking at implementing a new server for identity management and discovered IdentityServer. Is it possible for a user to self-create an identity out of the box? Otherwise, are there add-ons or code samples that would assist in doing something like this?
Identity Server can work with any user store, however only ASP.NET Identity and MembershipReboot is supported out-of-the-box.
If you want to implement your own user store to work with Identity Server, you can implement Identity Server's IUserService interface to abstract it out.
Identity Server itself is not an identity manager but instead an OpenID Connect provider that handles Authentication and Authorization using the OpenID Connect 1.0 and OAuth 2.0 protocols. See my blog post for a brief overview or the big picture section of the official documentation.
I started off in the same situation as you and ended up implementing Identity Server and migrating our user data from ASP.NET Membership to ASP.NET Identity. I would recommend the same for you.