I'm creating a centralized authentication system for multiple mobile applications. Its architecture is based on the OpenID Connect flow through the use of OAuth2.0 with IdentityServer4 on ASP.NET Core Identity.
I have researched a lot and in the main implementations with the Authorization Code Flow observed there is always the redirection of the user from the mobile app UI to the server web views, to allow the management of its profile.
This is very uncomfortable, because it significantly compromises the UX. I would like the user to be able to register and authenticate himself directly from the app interface without any redirection that involves opening a browser. Is there a way to do this with only API calls, from the client backend to the centralized authorization server?
You can use the Resource Owner Password Credentials grant type where you can pass the user credentials to the token endpoint and receive an access token. But usage of the ROPC grant type is highly discouraged as you can read in this blog post from Scott Brady, one of the creators of Identity Server.
What I can propose to you is to use Authorization Code flow to login the user and get access token for them, and then creating your custom API endpoints on identity server for user management. More on custom api endpoints here
Related
I am implementing a REST Web API for a service that will be hosted on Windows now (and on Linux in the future).
We are going to support custom credentials + token/refresh token using OAuth 2.0 and OIDC (via Identity Server 4), but we want to support also Windows authentication to allow integration with Active Driectory.
For clients which use windows authentication, is it better to authenticate once and get token/refresh token mechanism (as we do for credentials authentication) or is it better to authenticate each single request?
The latter option might be less performant as it needs to go through the challange every time?
My personal feeling is that if you're having identityserver4 in play already and the fact you've stated you will host the API on Linux in future that you should handle the AD integration in your identity server and have your API only worry about access tokens issued by said service.
I'd then recommend using ADFS (recent versions support OIDC out of the box) for the actual authentication of AD users and have your identity server act as an authentication gateway. If configured correctly you can achieve true SSO (i.e. the user is not required to re-enter their domain credentials) for any user already signed into the domain on their PC.
This just covers authentication however - how will you be doing authorization within this 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?
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 :)
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.
I've got a .NET web API that I'm trying to secure and want to allow a client application (angularJs) to make calls to it once it is authorized through the identity server. I want this authorization to be completely separate from user authentication/authorization. I don't want there to be any user interaction.
What have I missed?
I've seen a lot of questions regarding OAuth and using it to secure APIs using an external trusted provider.
However, in our organization, we have an existing ASP.NET MVC web application which contains a custom membership provider for authenticating users to use the web application. We are now developing an API (which will be accessed externally) which allows users of the API develop their own clients.
I am looking into different ways to secure the API without passing user credentials. The API will force HTTPS, but the security team does not want user credentials stored on the client systems. I have considered, a token based approach -- but most posts I have read here seem to suggest OAuth. Would the preferable route be some sort of OAuth implementation? And if so, how do I authenticate internal users who are not registered with a trusted provider?
Thanks!
One approach can be to use OAuth token created Microsoft ACS.
If each client user needs to be authenticated, you can use Microsoft ACS to create a trust relationship between you and the client organization (Id Provider) or even other Id providers such as Facebook / Google etc.
Alternatively you can also use service identities for each API client (assuming that each user does not need to authenticated) The clients gets a unique clientId and Secret created by your organization, that you can revoke when needed. The client requests a OAuth2 (JWT) token from ACS and send the token on each API calll. The API validates the token using standard OWIN library for JWT tokens.
I have a Web API application and I've understood OAuth would be the standard security model for APIs where an Authentication Server would become responsible to generate Authorization Tokens so that the user can send to our server and consume the services.
I'm very new to this but I understand the roles involved:
Resource Owner
Client
Resource Server
Authorization Server
But what is OAuth exactly in practice, not in theory? Is it a .NET library? Is it a service provided by a separate Company? Is it something I can configure on my local development machine and see how it works?
How to get started with OAuth to secure a Web API application?
OAuth is a protocol; the current version is OAuth 2.0. More to your question, that link lists several implementations of the protocol in various technologies. For use with the .NET Web API you're probably interested in DotNetOpenAuth which provides implementations of both OAuth 1 and OAuth 2.
I'm using DotNetOpenAuth in an app I'm working on now to secure a .NET Web API. I've got an OAuth2Handler which extends DelegatingHandler which is inserted into the Web API pipeline before incoming requests reach any controllers. OAuth2Handler does the following:
Instantiates a DotNetOpenAuth ResourceServer
Calls ResourceServer.GetPrincipal() which reads and decrypts an access
token (issued elsewhere by the AuthorizationServer and returns an
OAuthPrincipal (In my case I'm reading additional data that the DotNetOpenAuth implementation allows you to pass and creating a ClaimsPrincipal.)
Assigning the IPrincipal containing the user information read from the access token to the User property of the thread and current HTTP context so it is available from the ApiController.User property in the service controllers: httpContext.User = Thread.CurrentPrincipal = principal;
Honestly, getting this all working (e.g. setting up the authorization server, resource server, certificates, etc.) isn't trivial. Unfortunately there didn't seem to be a good guide on the DotNetOpenAuth site. Here's a few other tasks you'll have ahead of you if you go this route:
Implement IAuthorizationServer - This is the interface provided by
DotNetOpenAuth that allows you to plug in to the library and use
their implementation to issue OAuth2 access tokens. You'll also need to implement INonceStore and ICryptoKeyStore which I did using an EntityFramework context for storage.
Configure Certificates - The AuthorizationServer and ResourceServer each use certificates to encrypt/decrypt the access token ensuring they are only accessible to each other. I built some custom configuration so I could manage this configuration in the web.config files of my authorization server app and my Web API services (resource server).
Manage Refresh Token - When first requesting an access token from the authorization server you'll get back (depending on your configuration) both an OAuth2 refresh token and an access token. The services use the access token which should be short-lived. The refresh token is used to get more access tokens. The refresh token should be kept secret (whatever that means in your scenario). For me it means the refresh token is never exposed to client-side javascript in my web app.
I hope that helps give you a high level idea of how to get started with OAuth and .NET Web API. Here's a blog post demonstrating some of these steps. This SO answer gives a few more high level details of the client side of the picture.
(The DotNetOpenAuth online docs appear to be down right now... sorry for no links to them; Apparently it has happened before).