I'm building a small web application using ASP.NET MVC3, in which I'm using the default ASP.NET Membership API to create and authenticate users.
There's also a small desktop client which updates the web application. My question is what would be the best way to authenticate the desktop client. Considering that users would register using their username and password via the website, I don't really want to store any user credentials on the desktop.
I was thinking about implementing an OAuth provider in my web application, and associating the token with the authenticated username. That way I would authenticate my desktop client like most twitter clients do now.
So basically my question, should I do OAuth, or maybe there's another popular option?
Why not expose a login action method that returns a token? This would avoid the added complexity of an oauth service. As long as your mvc app is decoupled and using services, your client can consume these same services.
Related
My ASP.NET MVC web application is currently using on-premise SMTP server to send mails.
To understand, here is the classic scenario:
Users have to sign-in in the web app with a user/password (encrypted and stored in SQL DB)
Users fill in a form
When form is posted 2 mails are sent (one for the user and one for the team)
We have to migrate to an Azure VM (Virtual Machine) based solution. I am asked to use Microsoft Graph to send mails as a replacement of using SMTP server. I found a lot of documentation and tutorials on this subject. The classic solution asks the user to sign in using Open ID Connect and Azure AD is used for the authentication (MSAL). So a new authentication page is showed to the user where he should authorise the application to perform specific actions like sending mails (for example). See picture below.
In my situation, I prefer not force user to authenticate a second time. As explained in scenario above users already sign in with (basic) user/password not related to Azure AD.
So I thought I would use app's identity in place of user's identity. This way the user should not authenticate a second time. I found a quickstart on the Microsoft's website which seems to fit my needs.
Here is the link: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-netcore-daemon
Obviously I thought to integrate this concept in my ASP.NET web app and not in a console app but you get the idea.
So I would like to know if the solution of using app's identity in place of user's identity (authentication in Azure AD) to send mails in my ASP.NET web app is a good approach.
I think this is feasible.
In fact, Microsoft does not recommend users to log in to applications based on username/password, which requires a very high level of trust in the application and may bring certain risks.
In your question, you want to use the application to act as its own entity instead of performing operations on behalf of a specific user, so as to avoid repeated login authorization for users. I think this is a good method, but you have to pay attention, if you need to use the application's own identity request token to access MS graph api, then you must grant application permissions to the application, and then use the client credential flow as the authentication flow.
If you're using a VM you could enable managed identity and avoid dealing with credentials. Take a look to this article.
Im trying to implement IdentityServer authorization and my scenario is below:
we have one home page for all our application "www.vision2025.com" and i have link to my mvc application "MarketingDashboard" where users are authenticated by home page and redirect to my mvc application using windows authentication. Now user can do any action in my dashboard which interact to web API.
Now i need to implemented IdentityServer to authorize all the web API call from my dashboard but no need of login.
Please suggest any idea
Thanks in Advance
I think you don't want to build IdentityServer because your enterprise company has already built ADFS (Active Directory Federation Services). You just want to ask who maintain AD and ask him to enable ADFS for OAuth2. This is a page to help you catch all scenarios here.
Because I don't know how far you can change for all applications but there are some solutions with ADFS you can go with:
Let your main server (acts as Home Page and where user redirects to ADFS to sign in) performs On-behalf-Of flow. In this scenario, your main server will be a linked server that transfer its taken access token which retrieved from ADFS. I strongly recommend this way because you just want to add as many as your new upcoming web and api. The cons are they require you ensure protect highly access token in your main server
Because OAuth 2.0 doesn't support chaining Resource Servers yet (such as you signed in Resource Server A, then use provided access_token to call Resource Server B in different clients), you need to allow your main server store his username/password (also knew as trusted back end server , means your enterprise allows this server can store client credentials). So each time you redirect user to target MVC Application, you should transfer encrypted username/password as well. Then your target MVC application can perform Authorized Flow or Implicit flow itself in Back-end code, then returned new access token to client web to perform calling Web API.
At my company we are developing several web applications that uses a REST API server.
First a little introduction.
The app provides the ability to manage users through the REST API and allows the users to login to the app.
Right now the REST API is for internal use only because we plan to develop more apps and communicate to the REST API as the central point of data access. We are handling the REST API authentication with a "Resource Owner Password Credentials Grant" implementation for the internal apps.
What we need is a Single-Sign on service for all the apps, we want a user to login to an app and if he/she access to another of our apps he/she will be already loged in.
We have been experimenting with the CAS protocol, with the CASino library specifically and it works great.
The problem is we don't know how to handle the flow between the apps, the REST API and the SSO service, also I don't know if there is a better choice regarding SSO services.
My questions are...
How we could handle the flow between the apps, the REST API and the
SSO service, because the REST API should be stateless it should not
communicate to the SSO service? or is there a way to communicate the
REST API to the SSO service?
Is there a better choice to implement a Single-Sign on service,
maybe OAth or OpenID and are this options suitable for REST APIs?
Thanks in advance!
Your REST API will have to talk to the SSO server to validate the Access Token, unless all the information it needs is encrypted inside the Access Token. Not sure what you mean by "flow between the apps", you should have all apps talking to a central SSO server.
When a user wants to create an account on WebApp1, the account should be created on the SSO server, either by redirecting them there or if you need a differently styled signup form for each web app, then via an AJAX call to the SSO server's REST API. I would recommend the latter as redirecting is more difficult to debug and it can make a bad user experience.
Make sure the messaging is clear, i.e. not "Sign up for a WebApp1 account", but "Sign up for a MyCompany account to get access to WebApp1".
OAuth 2.0 is very popular and people have more experience with it, so it's easier to get help or integrate with apps created by others.
The doorkeeper gem is a good server library.
OAuth 2.0 is normally used when the SSO server doesn't trust the client apps (e.g. Facebook, Twitter), but it can be implemented in such a way to skip the client authorization step (where the user is asked to approve the client app), and you can use the Resource Owner Password Credentials Grant via a REST API.
CAS is easier than OAuth. It is fairly easy to implement the basic endpoints and that way you can customize it as you wish.
I worked on a CAS-based server with a custom implementation (not sure if it was even really CAS-compliant). The authentication was done with Devise (I don't recommend Devise if you're going to customise it a lot, make your own in this case). The original flow was that the user went to the website, clicked Login/Register and then was redirected to the SSO server and after the user logged in, redirected back with a one-time ticket that the website's backend exchanged to an access token via a REST API call.
Then we added a REST API that was called from each website with AJAX. You send the username/password/captcha/etc and get back an auth token, which the site sends to its own backend. The SSO REST API can also set a cookie on its own domain, so that if the user visit another of our web apps it makes a call on pageload to check if the user is logged in. This way you're automatically logged in on every webapp without the redirect mess.
All tokens issued + the associated user info were sent to a fast Node.js app that would save them to Redis, and the app backends would call this app to validate the access tokens really fast, without putting load to the SSO Rails app.
I'm looking for some guidance on what people think are the best set of technologies to use. We are looking to create a web portal to allow customers to register/login with standard credentials or their social accounts (Google, Twitter etc).
Once they are registered and logged in to the portal they can access our different web apps which will know who they are and what permissions they have based on a token. We will also need to secure a set of web APIs using some sort of OAuth mechanism, so the user would possibly create an account on the web app and then create an application which would give them the keys they need to access the API from their own app.
We have a basic portal app using MVC 4 and DotNetOpenAuth which allows a user to create an account and login with either a username and password or their Google, Facebook account etc.
The APIs would be MVC 4 Web APIs
Ideally the whole set up needs to be as simple as possible, I've briefly looked into using Windows Azure Access Control (ACS) as a way to cut out some of the heavy lifting but its hard to tell where exactly it all fits together.
Currently we run an ADFS 2.0 server and WIF to allow web login to our apps but it doesn't seem like it would be an ideal choice when integrating the social login and for securing the web APIs
I guess it could be two quite seperate parts, once they are logged into the portal, how would we go about providing some sort of claims token to the other apps they then access to understand who the user is and what they are allowed to do. And maybe the web API authentication/authorisation is its own entity?
Thanks for your time
We ended up using the built in MVC 4 login system and also added JWT token support, when a user is logged in a JWT token containing their claims is stored as a cookie. This is then automatically passed around our sites on the same domain by the browser, when the web API is called from javascript it checks for the token in the headers sent by the browser and either validates it and returns the correct data or returns an unauthorised response.
It doesn't cover all the bases, we can't give trusted third parties access to our web services yet
I'm working on an application which allows data entry and display from both a Windows Phone application and an MVC 3 web interface. Data access for the phone client is via authenticated WCF services hosted in the MVC 3 application. Users will be tracking information which is unique to them, so the service will only show me data which I have entered.
What is the simplest way to handle identity in this scenario? I'd thought of using Windows Live ID, since the phone application has access to a Windows Live Anonymous ID property. However, from what I can tell there's no way to get allow for a web-based Windows Live sign-in which gives me the same Windows Live Anonymous ID - Windows Live Messenger Connect login gives me a site-specific unique ID, which would be different from the phone client's Anonymous ID.
Alternatively, I could use Facebook authentication on both client and phone with Facebook SDK. My concern there is in securing the service calls. I'm thinking that the first time a device connects with the service with a Facebook ID, the server issues it a key, and both the Facebook ID and the server issued key are required for service access.
Thoughts on the above? Is there a simpler solution that I'm missing?
Dear Jon,
I have no experience on WP development but I have made a a little search for WCF Auth. for couple of days recently and found out that the apiKey auth is nearly the best way to me. Rob Jacobs has explained how it works on this article;
http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx
An alternative to an API Key is to use claims based identity and security tokens. You could use the Windows Azure Access Control Service as a trusted issuer of security tokens, with the value add that it comes pre-configured to use LiveID, Facebook, Google, any OpenID and any WS-Federation identity provider. Both the web site and the web service would trust ACS.
ACS will give you SAML tokens for the web site (allowing your users to login to it with LiveID, Google or FB).
ACS can also issue Simple Web Tokens (SWT), which are especially neat for REST services (assuming the phone client uses that).
You can't use the LiveID associated with the phone in your app, but you can still use LiveID (or any other identity provider). This is an example of how to do it. It uses the common approach of embedding a web browser in the phone app and use to for all security token negotiation.
Using ACS gives you a lot of flexibility without all the complextity. Making a web site "claims aware" and trust ACS is very straight forward. More samples here: http://claimsid.codeplex.com
If you need to link the Phone to a user on the MVC site you could do what Netflix and Amazon do for Roku and other devices and have some sort of an activation process. To make it easier you could use a QR Code or some other type of barcode generated by the MVC site, have the user take a picture of it, and process the image using the Silverlight ZXing Barcode Scanning Library. Probably a bit convoluted, but it works for all the set top boxes.