API Implementation Logic & Mocking Users

Help
1

I have a multi-tenant stateless REST API built in Symfony/Laravel which i’m aiming to outsource the authentication/authorization functionality for. I’ve read up on all the available tutorials but am still slightly baffled by parts of Auth0. We have multiple SPAs talking to the same endpoints which require a basic form of SSO. They have accompanying mobile apps.

The SPA/app does authentication in its UI and needs to receive access/refresh JWT tokens. The database is in Mongo, and has a “subscriber” foreign key on each user record to link it to the parent Auth0 record.

  1. Is there a purely JS way to get an access token from a simple login (i.e. design our own form), or does it have to be an OAuth2 modal with HTTP callback?

  2. Once a JWT access token has been received from Auth0, how can the (separate/remote) PHP backend check the validity of that token and the user’s permissions on each request? Having a middleware which contacts Auth0 each time is heavy on latency, and what happens if a user is deleted/revoked during the validity period of the token?

What i’m trying to ascertain is what the API should do when it is presented with a Bearer header - working on the assumption no input should not be trusted and all supplied data could be malicious or fraudulent. Is this as simple as parsing out the “sub” field of the JS and resolving it against the users table or collection?

  1. When creating/seeding mock (fake) users in the database, we need to associate each record with an Auth0 subscriber ID. Is there a way to create and delete “fake” users for testing purposes within the Auth0 database?

Thanks in advance!

2

Hi alex.c

Some quick answers:

  1. ROPG can be used, it is not a redirecting OAuth2 flow. However Auth0 does not recommend this, it is less secure than OAuth2 flows.
  2. Access tokens cannot be revoked. They should be short-lived due to this (and rely on sessions to get new ones without forcing the user to log in again). Verifying a token only requires public keys and doesn’t require contacting Auth0 every single time. Start with the docs here: Validate Access Tokens
  3. Check out the management API for user management.

John

3

Thanks John. I just need the first token for testing purposes before the UI guys do their thing.

I’ve had a look through that guide before but thanks for confirming no round-trips are required per-request. Just to clarify this (risking the fact it may be a dumb question), am i right in assuming the client has 2 connections? The first to Auth0 running a session and providing (short-lived) access tokens, and the second to the vendor API (via access token)? I have to explain this to our JS team who haven’t used Auth0 before so am looking for a simplistic conceptual overview.

We’re not interested in our API doing any session management or login logic - just taking tokens and providing data to authorised clients.