问题描述:

I have a backend built in Laravel 5.2 and the frontend built in AngularJS.

The site have a list of events and it make a GET request to the backend to get all the events.

How can I prevent that someone use my API to get the events on other site or via mobile app?

I want that the endpoint is accessibile only form my frontend.

Is this possibile?

What should I check?

API key is the way?

网友答案:

Use OAuth2. Most popular nowadays i think.

OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification is being developed within the IETF OAuth WG and is based on the OAuth WRAP proposal.

Here you have some extensive documentation how to use OAuth2 with Laravel.

The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.

There are many supported grant types in the OAuth2:

  1. Authorization Code

The authorization code is obtained by using an authorization server
as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its
user-agent as defined in [RFC2616]), which in turn directs the
resource owner back to the client with the authorization code.

  1. Resource Owner Password Credentials

The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).

  1. Client Credentials

The client credentials (or other forms of client authentication) can
be used as an authorization grant when the authorization scope is
limited to the protected resources under the control of the client,
or to protected resources previously arranged with the authorization
server. Client credentials are used as an authorization grant
typically when the client is acting on its own behalf (the client is
also the resource owner) or is requesting access to protected
resources based on an authorization previously arranged with the
authorization server.

  1. Refresh Token

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token (i.e., step (D) in Figure 1).

  1. Access Token

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the
client. The string is usually opaque to the client. Tokens
represent specific scopes and durations of access, granted by the
resource owner, and enforced by the resource server and authorization server.

  1. Implicit

The implicit grant is a simplified authorization code flow optimized
for clients implemented in a browser using a scripting language such
as JavaScript. In the implicit flow, instead of issuing the client
an authorization code, the client is issued an access token directly (as the result of the resource owner authorization). The grant type
is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token).

网友答案:

what you are mentioning is called Cross-Site Request Forgery CSRF to prevent it is using Header parameter specific for your server the stander name for it is X-Requested-With.

This header cannot be sent cross-domain via AJAX due to this header not being in the safe list (without CORS being enabled on your server). A HTML form cannot send this header either.

check this answer

if you want to use OAuth you can use client grant type as you are telling there is no user specific data, but I don't think it is the best answer for this situation.

相关阅读:
Top