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.
Related
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
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 am working on a project where we have different type of clients (winform App, ASP.net mvc, WCF service).
I need to implement security in it. Here is my plan...
There will be one service (planning to create as WebApi) to authenticate user.
client app will pass Windows identity to this authentication service.
Service will return authentication Token to user.
This token will be passed to WCF service for each call.
WCF service will verify this token using authentication service.
If user has correct permissions, then WCF will perform requested action.
If token expire then WCF service will renew the token using Auth service.
I am planning to use attribute based programming for Security for each WCF call.
I gone through lots of articles online but could worked out it.
can anyone point me to some article where I an find below...
Generate token based on Windows Identity.
How to pass token to WCF service for each call.
Thanks in advance.
I suggest using Access Token for authentication and refreshtoken to obtain renewed access token. You can store refreshtokens in database. If your scenario needs multiple client/device for each user then you will need to store unique deviceId with refreshtoken.Below helpful links for Access Token and RefreshToken:
Token Based Authentication using ASP.NET Web API 2, Owin, and Identity
Enable OAuth Refresh Tokens in AngularJS App using ASP .NET Web API 2, and Owin
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 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).