Completely LOST trying to build an authenticated Laravel Backend API

[kenprogrammer]

I just want to build an authenticated Laravel API. So I came across the following tutorial:

Build and Secure a Laravel API with JWTs

Publishing package configuration so as to generate configuration file doesn’t work. The context is completely different with the package documentation on GitHub. When I use the following Quick Start guide:
https://auth0.com/docs/quickstart/backend/laravel
The configuration file generated doesn’t indicate environment variables for client ID,Secret and the rest.

I DO NOT understand the use of JSON files generated as indicated on the guide. How can I set the credentials on .env file.

DISCLAIMER: The Backend API sample app provided on GitHub doesn’t work for me. I’ve wasted three days already trying to work with it.

[evansims]

Hey @kenprogrammer

Sorry to hear you’re hitting some challenges! Glad I spotted your message — I’m an engineer on Auth0’s SDK team, and I wrote and maintain our Laravel SDK and quickstarts for it. I’d be happy to help get you going on this!

The context is completely different with the package documentation on GitHub.

Could you clarify what you mean by context in this case? The guidance should, by all accounts, be identical, aside from the GitHub guidance being more verbose.

The configuration file generated doesn’t indicate environment variables for client ID,Secret and the rest.

The generated JSON file does not explicitly create anything that would be expected to translate to environment variables. Our CLI-based JSON configuration is a simpler alternative to setting up environment variables or editing .env files. The CLI commands generate a JSON-format configuration file. This JSON file contains the relevant Client ID, Client Secret, Domain, and other necessary configuration details. The SDK automatically reads from this file at runtime.

We offer extensive documentation on using the SDK in other configurations. Using environment variables is covered in our Configuration guide.

We default to suggesting the CLI/JSON approach as it is far simpler and a much less error-prone approach for developers, as it avoids needing to edit any files by hand.

DISCLAIMER: The Backend API sample app provided on GitHub doesn’t work for me. I’ve wasted three days already trying to work with it.

Sorry to hear that — in what way does it not work for you? I want to resolve whatever issue you’re facing there if you share your experience.

[kenprogrammer]

Given that the blog post was written in 2021 and it has been back linked on some sections on the docs.

The context is completely different with the package documentation on GitHub.

Generating SDK configuration:
Docs:

php artisan vendor:publish --tag auth0

Blog:

php artisan vendor:publish --provider "Auth0\Login\LoginServiceProvider"

Though publishing on the blog doesn’t work the config file shown is different from the one generated when following the docs.

The Backend API sample app provided on GitHub doesn’t work for me. I’ve wasted three days already trying to work with it

The Backend API sample app provided uses Laravel Sail which when you try to run says “Docker is not running” yet it’s. It could have been better if It was just a simple Laravel App. I just want to add the SDK to an existing project.

About the JSON configurations; since they are not version controlled what happens in production? I bet many devs prefer using environmental variables since it’s not easy to accidentally add secrets to version control.

One more thing:
I switched to using Session Based Laravel project using a Regular App Now after successful login I get InvalidTokenException “The JWT string must contain two dots”. That’s when calling the callback URL. I’ve just realized this is caused by the absence of IDENTIFIER/AUDIENCE, do I really need to create an API app when am using Session based authentication with a Regular App?

[evansims]

Hey @kenprogrammer

Given that the blog post was written in 2021 and it has been back linked on some sections on the docs.

Ah, I see where the confusion lies — that blog post you’re referencing is quite old, and is meant to demonstrate how to build a Laravel application that interfaces with Auth0 without using an SDK. It was accurate for the point in time it was written, but you should disregard the contents of that post and follow the quickstart and Github guidance today. Our SDK implementation is much more straightforward. Sorry for the confusion there.

I’ll ask our docs team about getting that updated to avoid future confusion around that.

Generating SDK configuration:

Please disregard the blog post, that was for a previous version of the SDK.

The Backend API sample app provided uses Laravel Sail which when you try to run says “Docker is not running” yet it’s. It could have been better if It was just a simple Laravel App. I just want to add the SDK to an existing project.

Apologies for the confusion; I assumed you meant our Laravel backend quickstart. Our maintained sample application can be found here, as linked in our quickstart.

For integrating with an existing app, just follow our guidance on our GitHub repository: https://github.com/auth0/laravel-auth0

About the JSON configurations; since they are not version controlled what happens in production? I bet many devs prefer using environmental variables since it’s not easy to accidentally add secrets to version control.

Whether it’s a .env file or .json file, one way or another, a file has to be ignored from version control. The point of a quickstart is to get up and running in as little time as possible, which the CLI and JSON format is excellent for achieving. As noted though, environment variables are fully supported as well.

I switched to using Session Based Laravel project using a Regular App Now after successful login I get InvalidTokenException “The JWT string must contain two dots”. That’s when calling the callback URL. I’ve just realized this is caused by the absence of IDENTIFIER/AUDIENCE, do I really need to create an API app when am using Session based authentication with a Regular App?

Yes, this is what’s referred to as an opaque token. You’ll want to provide a identifier/audience in order to retrieve a valid access token.

[kenprogrammer]

Thanks for the clarification. When I installed the SDK on an existing API project the Authorization Guard stopped working. Whenever I tried authentication with Sanctum from SPA it failed with exception ‘Undefined Authorization Guard’ Does it modify the Laravel default guard configurations?

Am using Sanctum for the project just wanted to use Auth0 for some endpoints being accessed and updated from outside the organization.

NB: The project is huge and time-bound so maybe in future I’ll change everything to use Auth0.

[evansims]

Thanks for the clarification.

No problem!

When I installed the SDK on an existing API project the Authorization Guard stopped working. Whenever I tried authentication with Sanctum from SPA it failed with exception ‘Undefined Authorization Guard’ Does it modify the Laravel default guard configurations?

Offhand I’m not sure what would trigger that exception for you, to be honest. The SDK doesn’t manipulate the default Guard configuration, just registers its own Authentication and Authorization guards. You can learn more about how that works here: https://github.com/auth0/laravel-auth0/blob/main/docs/Configuration.md#guard-registration We’d probably need to open up a GitHub issue to diagnose that one deeper, if you want to dig in together and figure out what might be going wrong there.

Am using Sanctum for the project just wanted to use Auth0 for some endpoints being accessed and updated from outside the organization.

NB: The project is huge and time-bound so maybe in future I’ll change everything to use Auth0.

Sounds good! Let us know if we can help migrate you over fully in the future