I have an MVC application built that uses forms authentication and stores credentials encrypted in AspNetUsers
I also have a web api application that using that same store of users and is secured with oAuth.
The api is tested and works from an javascript app (going to be deployed on smartphones).
Now I also have a need to access the same API from the MVC app. Basically the user is already logged in an authenticated, but as far as I can see, in order to get an access token from the API (calling the api/token endpoint) I need the users password, which is one way encrypted in the DB.
The API and MVC app are deployed as two separate apps.
I guess one way I could do this is to grab the access_token when they first log into the MVC app and store it in the user table.
Is there a another recommended way to handle this in the .NET world?
Thanks
Related
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.
I'm developing a website that will be loaded for genuine users(without registeration or login requirement) using API for front-end data. I want data to be secured.
I read about authentications and thus created secret key at server end but stuck at a point as to how can I create secret key for clients and verify the user is genuine and no attack to website is done.
I'm trying to figure out if this is an anti-pattern or if this is a valid way to do things.
I have an MVC5 web app that accesses a Web API. I manage identity via ASP.NET identity 2 via the MVC app.
I'm trying to figure out how to issue an OAUTH2 bearer token from the MVC app to send to the Web API, and then how to access the claims from the token in the API.
I'm assuming as long as the app and the API share a machine key that I can somehow decrypt the token at the API (correct me if I am wrong), but how do Icorrectly issue a token from the app? Is it fair to assume that I can just use OAuthAuthorizationServerOptions to create a token endpoint on the MVC app, then get the token from here prior to calling the Web API?
All of this makes sense to me, I'm just looking for reassurance that this is the right, or accepted way to do things in this scenario.
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 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.