There is a project I am working on using asp.netcore 3.1. d app is a web API and will b consumed by multiple clients(web browser, android and Windows forms). How can I build the OAuth2 server in c# to protect my API.
Most companies don't build their own Authorization Server, since it is a job for security experts. Instead they use a cloud provider, and these are often very low cost or free.
In the early days this is a good learning guide and will save you a lot of time. You can then focus on OAuth integration into your UIs and APIs.
As long as you keep security in your UI and API standards based you will then be able to easily swap between providers later - or use an open source one perhaps.
Here are a couple of resources of mine that you might find useful. My early code is in NodeJS, but based on OAuth messages, so easily translatable to .Net Core:
Setting up an Authorization Server
Initial Tutorial
OAuth Messages - see Step 16 for API Integration
Related
I'm currently on a project where there is an existing angular 1.3 app with a couple of API's. These are secured via Azure Active Directory.
The customer has asked for a new tool to be developed that uses these same api's but they want to get rid of the AAD because it's tokens are only valid for 1h and I've been told that refresh tokens and AAD are not working according to those that made the current setup.
I've been reading up a lot on IdentityServer4 and I was hoping to leverage the middleware in order to
a) start using an STS
b) prepare for the future and make the STS a central part to the whole installation.
I've been hoping that I could use IdentityServer4 with a new to be developed Angular4 app with an Asp .NET Core 2.0 WebApi.
The question that I have is: can I do Active Directory based auth (the users are logging in through some citrix alike product) and thus are authenticated because of that. Yet somehow still calling the existing api's with some token that is valid in their context.
And can I use IdentityServer4 to pull this off? Is it a good idea? I'm open for suggestions
Edit
After careful delibiration with the client we've agreed to remove AAD and the token security that currently is in place.
The reasoning:
All installations are done in a DMZ
It's not Azure
The customer isn't willing to change that
This way everything can be secured using Windows Authentication
Time constraints
IS is on the planning for when (5) loosens up
A lot of new tech is going to go in the new client which enforces (5)
I am hoping someone can clear up how these things can work together.
I want to be my own identity provider, so in my web api I have an OAuth token provider. I want users to register with me and then be authenticated using my token provider. The idea in the future is that more of my mobile apps and web apps will be accessible using the OAuth login sharing the user's identity.
So, if I use azure mobile services how do I implement the normal asp.net identity stuff?
And, how would a normal web app be able to use the data stored in azure mobile services? Would I have two dbcontexts one for mobile and one for web?
I've been reading and watching a lot of stuff on azure but nothing seems to show how I can do this. Most of it has to do with using external providers like facebook, ms, twitter, etc. I want to be one of those external providers, just not sure how to do it and allow my websites to still use the .net identity data.
If you could point me to or post some example / tutorial / blogs that would be great.
This is a supported scenario, although it isn't documented very well at the moment.
The Mobile Services .NET runtime is built on the ASP.NET Katana authentication middleware. The mobile service abstracts these middleware using the LoginProvider base class. The authentication model was recently made extensible for situations such as yours. In order to have Mobile Services recognize and use your identity provider, you would have to create your own LoginProvider.
There are currently two examples of this:
Adding a Katana middleware as an identity provider - part of this post.
Creating a custom username/password setup - tutorial here.
You could certainly use these techniques to wrap the standard ASP.NET identity functionality.
As to your question about accessing the data, there are a variety of approaches. Your web app could treat Mobile Services as a backend and pass through requests. This is basically treating the web app as an additional client platform, peer to your mobile apps. Another option is to, as you said, create multiple DBContexts. While you might get slightly better performance, this comes with a code maintainability tradeoff. It also wouldn't scale well if you build multiple web apps on the same data backend.
I am looking to write an auth service using Web Api, and SQL Server for authenticating and authorizing users on my .net site, but ios and Android apps as well. I'm speculating that basic authentication over SSL is the easiest way to go, but I'm pretty new to this whole section of .net. I'm having trouble finding some clear tutorials that explain how to write such a service. Can anyone point me to some resources on how to do this? I'd appreciate it.
I think you need to look OAuth implementation in .NET.
Here is a video to give you some background on Web API security.
I also suggest getting a trial subscription to Pluralsight training and check out the courses on Web API security.
You may want to target the latest release of Web API 2.0 from Microsoft, it has the most features you'll need.
I think this might be useful for you:
http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api
I have an application running on a server that periodically extracts data from Google Analytics. It doesn't issue many queries so I don't think any limit would be a problem.
I have a prototype running, however I had to provide a login a password for the authentication (in code).
I see that I can generate API keys and other kind of authentication bits and pieces in the Google APIs Console, however I am not sure how to use them and whether they can be used in place of the login/password.
It just doesn't seem right to use a user login/password to authenticate a server application.
Is there another way?
(I am using the C# client library)
You should be using OAuth 2.0. See:
http://code.google.com/p/google-gdata/source/browse/trunk/clients/cs/samples/oauth2_sample/oauth2demo.cs
for a sample OAuth workflow.
The best way to do this is with Google Service Accounts
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
However, I don't know off the top of my head the best library for c#, but there does appear to be support for it in the Google library. http://code.google.com/p/google-api-dotnet-client/wiki/OAuth2#Service_Accounts
Here's a answer specifically about the PHP client.
Service Applications and Google Analytics API V3: Server-to-server OAuth2 authentication?
Currently I'm developing some infrastructure and I've implemented my own RESTful authentication mechanism.
Now I've in mind that maybe I shouldn't go this way and use an industry standard so interoperability with my project could be trivial and easier to understand in terms of authentication and authorization.
After checking some articles googling everywhere and reading some Q&A here in Stackoverflow, I don't find how to be an OpenID provider - I'm not talking about authenticate users using Google, Windows Live, Facebook Connect and so, I want to develop an OpenID-enabled system so if some want to register into my services, they'll do in my own domain -.
Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?
Thank you.
Developing an OpenID Provider as a means of Single-Sign-On (SSO) within an organizations ring of web sites is a very valid scenario. DotNetOpenAuth comes with a pair of sample web sites (a Provider and a Relying Party) that demonstrate a single-sign-on relationship. They're called OpenIdWebRingSsoProvider and OpenIdWebRingSsoRelyingParty.
Please do not attempt to implement OpenID by yourself any more than you'd implement SSL by yourself. Getting OpenID security and interoperability just right takes a very long time and a deep level of domain knowledge. DotNetOpenAuth in particular gives you programmatic access to do just about anything you'd want to with OpenID, and since it's free, it's hard to go wrong.
Disclosure: I am a developer behind DotNetOpenAuth.
Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?
How to become an OpenID Provider
DotNetOpenAuth has some hiccups but all-in-all is a good tool to use it under .NET
if you're think you can do it, you can follow this:
Lastly, and most challenging, is implementing custom support for OpenID in your software and account management tools. While this approach of course affords the greatest degree of control over the user experience, it is also the most risky and only for developers experienced with web security. Start by reviewing the specs and documentation.
But my question would always be:
Why one more provider? Facebook, Google, MyOpenID, ... already have it, and with them, plenty of users have (even without them knowing) an OpenID login...
StackExchange is an OpenID provider since a while ago, but... there's so much users cross StackExchange platform. Are you developing such a big community so it will be reasonable to create and implement your own provider?
I see the answers are couple of years old. If you are looking for the latest solution to build an OpenID provider using Microsoft technology stack, IdentityServer is the open source option. One can use this and build an Open ID connect Identity provider.
Documentation on how to use and build : https://identityserver4.readthedocs.io/en/latest/
IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2.
It enables the following features in your applications:
Authentication as a Service
Centralized login logic and workflow for all of your applications (web, native, mobile, services). IdentityServer is an officially certified implementation of OpenID Connect.
Single Sign-on / Sign-out
Single sign-on (and out) over multiple application types.
Access Control for APIs
Issue access tokens for APIs for various types of clients, e.g. server to server, web applications, SPAs and native/mobile apps.
Federation Gateway
Support for external identity providers like Azure Active Directory, Google, Facebook etc. This shields your applications from the details of how to connect to these external providers.
Focus on Customization
The most important part - many aspects of IdentityServer can be customized to fit your needs. Since IdentityServer is a framework and not a boxed product or a SaaS, you can write code to adapt the system the way it makes sense for your scenarios.
Mature Open Source
IdentityServer uses the permissive Apache 2 license that allows building commercial products on top of it. It is also part of the .NET Foundation which provides governance and legal backing.