I've got a SPA application which gives statistics and information to anonymous users. It is a react spa app and will consume backend REST Web API(.net core). These data are not specific to users, therefore the information is freely available and no user authentication is required. However, I don't want my Backend Api layer to be exposed to the internet (i.e not use by anonymous applications such as postman, rest clients, etc). I'm familiar with the Client credential flow (OAuth) but I can't use it for this application because there is no concept for user login in this application.
What would be my best options that limit access to my API layer to anonymous applications (i.e postman, etc), or is it not possible at all?
You can't use client credentials flow for your SPA. Anyone would be able to download your SPA, extract the client id and secret and use it to call your API.
If you do not want to authenticate your users, there's no good way to protect your API. Move your SPA to a traditional web application hosted on a server to protect it using client credentials flow.
It's not possible to make an API accessible to a public client (your SPA) without also making it accessible to users making API calls from Postman or custom code. It's possible to do the reverse, only because of the limitations that browsers put in place.
Depending on what you're trying to achieve, you could use something like reCAPTCHA to validate that the users of your API are humans, not scripts. That along with human-scale rate limiting would probably filter out most of non-app users.
Related
I have a DashboardApi and an EnterpriseApi on my system. May be one more later.
I am new at IdentityServer3 and I wonder solve my problem.
IdentityServer saves client applications that will use an api. So I have 2 or 3 api. Will I create IdentityServer for all api? Because DashboardApi will consume EnterpriseApi. EnterpriseApi will consume another api.
And users will login to Dashboard application. I could not imagine the organisation.
To answer the question: you may have one instance of IdentityServer being your identity provider/authority across different "resource" APIs as long as they all point back to that same authority when it comes to token validation.
Then an access token used for "DashboardApi" can be used by "EnterpriseApi". It is important to proxy the token properly and in my experience it would be advantageous to create different scopes for each API to have better access as to which calls may be used to proxy into the second API through the first (especially if user consent is a concern).
We are building a JSON API on top of our Web application, using JSONAPI::Resources to expose endpoints and Doorkeeper to handle user authentication.
Most of our API endpoints will be exposed only to authenticated users, and Doorkeeper will probably do a great job at enforcing that. But we still have a couple endpoints that will not be authenticated: signup, login, account confirmation, and maybe a couple others.
I am worried that letting those API endpoints completely open will expose us to attacks, in the form of spamming new accounts for example.
Maybe I am worrying more than necessary? Do APIs usually let this kind of endpoint unsecure, and add prevention systems like throttling? (Rack::Attack!!!?)
If not, is signing (or encrypting) my requests before sending them to the API server the right approach?
And if that's so, do you have any recommendation, or preferred approach, in doing so?
I tried to Google keywords like "rails api sign request" or "rails api encrypt request", but I'm not sure the results are pertinent, or which one would be recommended.
The first clients that will talk to this API will be Android then iOS applications, and we might add in the future client-side web applications (at the moment, our web application is monolithic and does not use the API).
i'm new to asp.net web api, owin, and everything related to it.
I'm trying to find the best way to do this scenario:
1 - Web api to have all the connections and rest service
2 - Web site to show data to user on a browser using the restful service
3 - An mobile app that have some functionalities like the web site and access the restful service to get all the information
My doubt is: what's the best practice related to the login? I'll use owin/oath2 with Identity to login, but since it's going to be implemented on the web api, the login/register/forgot password should be on the web api directly (like the project template does) or should i move most of the functionality to the web site? Of course its easier to leave in the web api, but if i do it, i must duplicate my razor templates just to call the login part. Can someone give me a path to follow?
Thanks!
the answer is not, your web api should not have any html or js or css file, only the services that your need, the web api exposes the functions to register the user, next when you have to do request, you must Send a token, you can obtain the token using the URL that you have configure in owin, the URL is like /token and Send the username and pass.
Regards,
I am developing an ASP.NET MVC web application. The application is consuming a REST API, but authentication for REST-full application is quite unclear for me.
As REST is stateless, do I have to implement two different Authentications with two different databases, one for client, and one for the REST service?
Or, do I have to send the login/password each time, to authenticate on the server?
Please give me some advice or tutorial on this.
You can authenticate a Web API using individual user accounts that are stored in a database.
In this case client should obtain access token first. And then include it to each request, that requires authorization, header:
Authorization: Bearer boQtj0SCGz2GFGz[...]
Good tutorial can be found HERE
Also authentication methods could be extended in Startup.Auth.cs with Cookies or some external authentication methods (Google, Facebook etc)
The stateless isn't a main problem in your situation, problem is that browser can only send GET or POST request in tradition way in tag form, so to send PUT or DELETE request you should use Ajax, the easiest way is to use JQuery library and config it to send user credentials in http header(between requests it can be store in cookies) in every request and use basic-authentication if you plan use own auth logic. I recommned you to look some SPA frameworks like angularjs
or emberjs
or backbonejs
to simplify your life from hardcode JavaScript . Also in future you can easy extend your auth by OAUTH 2.0.
I'm developing a service that has two components - a web interface and a REST API. I use ASP.NET MVC and ASP.NET Web API, respectively. The two components are hosted on different subdomains of the same domain.
I want the REST API to be used by both external users and the web interface, and I want to simplify authentication as much as possible.
The REST API currently only supports basic authentication.
The web interface uses forms authentication and thus generates an ASPXAUTH cookie. The web interface interacts with the REST API using AJAX calls.
My question to the community is:
How do I authenticate the AJAX calls from the web interface to the
REST API, using the most elegant and secure method?
Some ideas:
Send the ASPXAUTH cookie in the ajax calls (by changing the cookie domain to ".myservice.com" to allow cross-subdomain read) and adding an authentication method in the API that reads the ASPXAUTH. Not sure if this is a great idea, or how to implement this.
Storing the user name and API key in separate cookies. Not really safe unless the values are encrypted/hashed.
Using OAuth in the web interface and rest api, instead of forms + basic authentication?
Ok, I've come up with the following solution:
I've added form authentication to the REST API and made sure not to use IsolateApps in the <machinekey>section of machine.config. This ensures that the REST API can use the same ASPXAUTH cookie. I'm making sure to fall back to basic authentication if no ASPXAUTH cookie is present.
Since there's no way to include the ASPXAUTH cookie in ajax requests to a different subdomain due to the Same-origin policy (even though the cookie's domain is ".myservice.com"), the solution I chose was to add an application (through IIS) to the web interface with the name "api".
The ajax calls now point to "/app.myservice.com/api/..." instead of "https://api.myservice.com/...", and the ASPXAUTH cookie is included and works.
Not sure if this is the best solution, but it's both clean and secure. Only tweak is the sharing of machine keys. If running in a web farm you would need to set the same machine key to all machines.