@thush - First, I appreciate your detailed posts here and checking back in with what you came up with. The time you spent here will definitely help other folks. Hopefully I can add a bit of clarity to this.
If I understand correctly … you are building a native application. While I can’t speak to Nativescript-Vue, I can hopefully help with the idea of a native app calling a Laravel API. I’ll answer some of your previous posts as well in case you still had some lingering questions.
When the user authenicates on the native app I get information such as an accessToken (although it seems quite short?
The access token you were seeing in your first post was one that is meant to be used against our userinfo endpoint (sends back the same user data that comes with the ID token).
So to follow up on this, I realized that if I change the audience for the webAuthentication() as shown here … To match the Identifier of my Auth0 API, then I am able to successfully authenicate and call the Laravel API.
You got it Adding that
audience to the request tells Auth0 that the native application wants an access token.
This would work completely fine but I feel like its a bit botchy? As in theory it allows for any authenicated request to get any user’s data provided the specific email is given?
Once again, totally on the right track here. When your native app sends a user to login with that
scope, if your API is built to provide different capabilities based on different scopes), it’s requesting access to the API on behalf of a very specific user, the one logging in. As such, the API should only be providing the data that that specific user has access to.
Since in case tokens are comprised they shouldn’t be able to be used to get other user’s information.
Even if it wasn’t compromised, you still want that the data returned to be specific for the user (and scope) of that access token.
I thought that you had to create a Auth0 application for each type of platform you deploy to…
You should have an Application created for each application that you’re creating that a user can log into using Auth0. That’s a bit of a mouthful but … the native app definitely should have an Application and the Laraval-served API should have it’s own API. If you’re using Auth0 to log in to the “emit analytics” app as well, then that record is fine. The “emit API” test application is created automatically and can probably be deleted.
But I added aditional callbacks for my regular web application and modified Token Endpoint Authentication Method to none, then I was able to authenicate the user on my native app through the Auth0 “web application”
Your tenant doesn’t really care what app is doing what, really, and the application type that’s there is mostly to help guide you with the UI. If you create a regular application and then give that Client ID and Domain to a native app, it should work fine.
this then gives me an jwt access token (which allows to me to access my Laravel API routes with a jwt middleware BUT not my standard Laravel routes secured by the auth middleware) and a seperate id token (which contains user info).
So when I do the authenicate with the jwt access token, I noticed that the jwt itself contains a “sub” in the payload data → therefore I can use this with my user repository in Laravel to find the specific “User” model, and then do following actions from there!
but I do still have a couple of doubts if I’m doing everything by best practice, I’m still unsure about this whole Auth0 “applications” thing? i.e. should I have a separate application for my Laravel Web App and Native App?
I explained that above but it can’t hurt to go through it again.
Each entity that is accepting logins (or obtaining access tokens to call APIs or both) should have its own application, which will generate its own Client ID that you use in the individual applications. If both the web app and the native app pull from the same pool of users (as in, if I log into the web application with the same user account as the native application) then they should share the same connections (same database, if you’re using that, same social connections).
Hopefully that helps iron things out. It’s clear to me from this thread that we could be doing a better job of explaining all of this in our quickstarts and documentation. Once again, thank you very much for typing all of this out!