I've created my first mvc 4 project using the web api template. I've configured CORS to restrict other sites from accessing my api directly into other websites. I use ajax to retrieve the data supplied by the api into a web page and that works well.
The address to my web api is http://www.xyz.com/webapi/ one of the actions is http://www.xyz.com/webapi/api/sales How can I prevent anyone from accessing /webapi and /webapi/api/sales and using the data (screen scraping) for their own use. I do not want any other service browser accessing the web api, just the ajax query that is present on another website that I've set up.
Thanks in advance!
Approach 1 - Get a Bearer Token
You could implement this - Individual Accounts in ASP.NET Web API
Here in this tutorial, the controllers are marked with [Authorize] and the following steps are followed.
Register a User
Authenticate and Get a Bearer Token
Send an Authorized Request
Approach 2 - Use a private API Key
You could use an api key with each of your web api calls and check on server side if the api key is valid if not return 401, Unauthorized. This api key could be saved in your web.config file.
Related
I'm trying to use Google Authentication in a VS2015 solution with 2 Asp.Net projects:
an MVC App and
an MVC WebApi.
Logging in with a local username and password works fine. I get back a token after logging in with api/Token from the API and can use this on subsequent httpclient calls to api/xxxxxx methods decorated with [Authorize].
Now I want to add the option to log in with a Google account. I have have managed to get the call to Google working on the front end and get back an Owin.ExternalLoginInfo object, but of course calls to the api/methods fail with
unauthorized.
Can someone tell if it's possible to push that ExternalLoginInfo back to the API and have it be used for authentication in the backend?
I want to implement Single Sign On in Angular 5 SPA which uses ASP.NET Core API. I have OAuth2 server provided by the company.
What I want to achieve is to allow access to the application only to authorized users, who have to pass through SSO process. I want to display content of the SPA only to authorized users and allow to access API resources only by them (users with correct access_tokens), too.
I do not know what should be the correct approach for this requirement. I was considering:
Implicit grant flow - from my SPA myspa.com:4200 I am invoking mycompanyauthserver.com/Authorize to obtain authorization code.
With that and client_id in Angular app I am invoking mycompanyauthserver.com/Token to obtain access token. I save it in localstorage. Now, I can send this access token with request to my API (myapi.com:5000), but how to check in API if this token is correct? I do not have endpoint on OAuth server to do it. Also, how to check on SPA if access code is correct and not manipulated by user?
Another approach I see is to invoke from SPA some endpoint in my API which will invoke mycompanyauthserver.com/Authorize and then mycompanyauthserver.com/Token and then API will have access_token and return it to SPA. Then, I can easily check while sending request from SPA to API if the access_code is the same. Is the right approach or am I missing something?
Does your SPA really run on localhost:4200? This would make it a native application, where you could possibly make use of other grant types like Auth code with PKCE. Or is localhost:4200 just a local/dev version of your SPA?
If your app is a SPA, and will be served html and javascript from an external web resource, then yes the implicit grant is optimised for this scenario.
But even so, if your external web resource (which serves up the SPA) can also provide and register a redirect endpoint which can interact with mycompanyauthserver.com/Token endpoint, then you can use the authorisation code grant and return the access_token from your server-side redirection endpoint back to your browser - similar to what you suggest in your option 2.
I'm not sure there's a correct approach.
I've seen SPAs use both approaches. Option 2 involves more server-side code to manage tokens. Option 1 simplifies getting a token but won't give you a long-lived/refresh token. Take your pick :)
I have created a new web api project with individual user account authentication.
I followed this post and everything worked as expected
http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
Now, I have a token end point
localhost:54452/Token
Lets, say I create new asp.net mvc application. I want to use this token end point for authentication. How do I tell my controllers to use this token end point? How do I tell my controllers to pass the bearer access token on each request or how does these two work together.
asp.net mvc and asp.net web api are two different projects with different port numbers
Thanks,
Syed
I would create a wrapper class that uses HttpClient to issue HTTP requests to the Web API. Then use this wrapper class when you're communicating with the Web API. It will then handle adding the token to the HTTP request header.
I am successfully using bearer token authentication for asp.net web API as is demonstrated in the default single page application template. But now I want to use the same web API from a different site (a different url).
When I make a request to web API AuthorizeEndpoint(by default /api/Account/ExternalLogin) from different site, I get error: invalid_request. I guess the problem is in the redirect_uri value, since changing that to value of site running on same domain as web api resolves the problem.
ValidateClientRedirectUri method in application OAuthAuthorizationServerProvider doesn't get fired. So based on my search in Katana source the error origin is in OAuthAuthorizationServerHandler.InvokeAuthorizeEndpointAsync.
Does anyone else have the same problems or am I doing something wrong?
The Katana OAuth middleware is not designed to be cross application - it is mainly for "embedding" an OAuth authorization server into the business resource.
If you want a proper (free) authorization server - have a look here:
https://github.com/thinktecture/Thinktecture.AuthorizationServer/wiki
The bearer token appears to be a hash into an claims hash, which is local to your application.
We are using a jwt token with a separate validate handler. Works cross application.
Still looking for a better way but for now it works.
I am trying to do something like this:
I have a MVC4 Web App and a Web-API service (hosted on two separate roles in azure)
Another role runs CustomSTS1.
The MVC Web App trusts the CustomSTS1
Now the customer logs into the site he is redirected to the STS login page.
Once logged in, he is redirected back to the MVC Web Site.
From this web site, the customer performs actions, which in turn invoke the web-API Service.
I have the SAML token in the web app, which I pass to the WebAPI service.
Now when I try to validate the SAML token at the Web API side, I get a
Message=ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement, or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.
This is without the Web API service trusting the CustomSTS1
Once I setup the trust,
I am always given a HTTP 401: UNAUTHORIZED, whenever I try to make a HTTP Get request to the WEB API Service.
Now, My Question is, (I know that my current approach is definitely wrong)
How do I setup the Trust relationship with the CustomSTS1, such that the WebAPI service is able to do an ActAS on behalf of the user logged into the MVC site?
OR
Is this architecture wrong?
And is there another way to achieve this?
That approach is wrong conceptually. The MVC application should negotiate a new token for the Web API in the STS using ActAs. That's how it traditionally works for SOAP Services. However, Web APIs are moving away from SAML as it is a complex format that relies on different WS-* specs. OAuth 2.0 is becoming the standard in that area if you want to support SSO at that level.
Another approach is to establish an implicit trust between the MVC app and the Web API, so all the calls to the Web API from the MVC app are done through a more standard Http auth mechanism like Basic Auth using an specific set of credentials that only the MVC app knows. The info about the logged user in the MVC app is passed as additional information.
Regards,
Pablo.