Making Unauthenticated Requests

Making Unauthenticated Requests

By default, Liferay DXP restricts API access for the sake of security, requiring authentication in order to get a valid response. However, in certain cases it may make sense to open up an API for guest access.

Making an API request without passing credentials generally leads to an error response:

curl localhost:8080/o/headless-admin-user/v1.0/sites/20122
  "message" : "Access denied to com.liferay.headless.admin.user.internal.resource.v1_0.SiteResourceImpl#getSite"

If you need access to an API without credentials, then grant unrestricted access via a Service Access Policy.

Relaxing API Restrictions via Service Access Policy

You can use Service Access Policies to define API access at a granular level.

  1. Visit your site with your browser at http://localhost:8080.

  2. Sign in using the default credentials:

    User Name: Password: test

  3. Go to Global Menu → Control Panel → Security → Service Access Policy.

  4. Click Add (add).

  5. Give the policy a descriptive name. It makes sense to call it something like “SITE_API_GUEST_ACCESS”.

  6. Switch the Enabled toggle to enable the policy.

  7. Switch the toggle labeled Default to apply the policy to unauthenticated requests as well as authenticated requests.

  8. Give the policy a localized title, like Grant Guest access to the Site API.

  9. Click Switch to Advanced Mode at the bottom.

  10. Copy and paste the method signature from the error message above: com.liferay.headless.admin.user.internal.resource.v1_0.SiteResourceImpl#getSite.

  11. Click Save.


Make sure to use Liferay’s external headless API classes instead of Liferay’s internal service layer classes in your policies.

Service Access Policies define rules for access to APIs.

Your Service Access Policy is now active, granting Guests access to the Sites API.

Confirming Access

Now that the Service Access Policy change is applied, the API call that previously failed now succeeds:

curl localhost:8080/o/headless-admin-user/v1.0/sites/20122
  "availableLanguages" : [ "en-US" ],
  "description" : "",
  "friendlyUrlPath" : "/guest",
  "id" : 20122,
  "key" : "Guest",
  "membershipType" : "open",
  "name" : "Guest",
  "parentSiteId" : 0,
  "sites" : [ ]

You can apply this pattern to open access to any headless REST API. Leverage the flexibility of Service Access Policies to make this as granular as you need.


Service Access Policies can’t discriminate between GraphQL APIs as easily as Headless REST APIs, since all the APIs are consolidated under a single endpoint. So while opening up GraphQL access like this may work in some cases, it isn’t generally recommended, because you might accidently grant access to too much data.